How to Use GitHub Copilot Assisted Permissions

If you use an agent in the terminal, you know the rhythm. It wants to list files: allow. Read a config: allow. Run the tests: allow. After twenty prompts you stop reading them and just press Enter. On October 26, GitHub made GitHub Copilot assisted permissions generally available, and it targets exactly this problem.

What GitHub Copilot assisted permissions does

When Copilot wants to run a shell command, touch a file path or open a URL, a second model reviews the request first. If it is confident the action is safe for the task you gave, it runs. If not, you get the normal prompt. Your existing allow rules are checked before the review, and enterprise deny rules always win. Requests to bypass the local sandbox always go to a human.

It works in Copilot CLI, VS Code and the GitHub Copilot app. It does not work in cloud sessions. The details are in the official changelog and the GitHub docs page.

Who it helps

• A backend engineer running long agent tasks. You ask Copilot to fix a flaky integration test. It needs to read logs, run the suite many times and search the code. Today you babysit it. With assisted mode, the boring reads and test runs just go, and you only see the prompts that need a decision.
• A platform or DevEx lead. Many teams are tempted to just "allow all" and move on. Admins can now block allow all, keep assisted available, and set the default mode for new sessions. That is a middle way you can defend in a security review.

How people react so far

It is only two days old, so there are no big user stories yet. The first careful write-up I found is a DEV Community post from October 27 with a useful warning: in Copilot CLI, an enterprise "ask" rule for shell commands, files or URLs can now be satisfied by the model, not a person. So "ask" may not mean "ask a human" anymore. The author suggests recording, for each request, whether a rule, the model, a person or a deny decided it. I think that is good advice for any team.

How to turn on assisted permissions

1. In Copilot CLI, run /permissions in a session and select assisted.
2. In VS Code, open the permissions picker and choose Assisted permissions.
3. In the GitHub Copilot app, open the mode picker, then Tool permissions, then Assisted.

Then try it on a throwaway branch with a prompt like this:

Run the unit tests, find the three slowest ones and explain why they are slow.
Do not change any files.
Ask me before any command that writes, deletes or uses the network.

Watch which steps run alone and which ones stop for you. That tells you more about the review model than any doc.

The honest part

GitHub itself says the model can make mistakes and approve dangerous or unintended actions, and that this is not a replacement for sandboxing or access restrictions. Run agents in a container or a dev environment when you can. The announcement does not say which Copilot plans include it, or whether the review costs premium requests, so check your usage after a few days. And if you run Copilot in scripts, read the docs first: if assisted mode fails to turn on, the CLI only prints a warning, and an older allow all tools setting still applies without any review.

If you like practical AI tips like this, subscribe to my newsletter. One short entry a week, straight to your inbox.

Sources

• GitHub Copilot assisted permissions generally available (GitHub Changelog)
• Allowing safe commands to run without manual approval (GitHub Docs)
• GitHub Copilot assisted permissions: how it works and how to enable it (Data Studios)
• GitHub Copilot's "Ask" rule may not ask a human (DEV Community)