Copilot CLI's assisted permissions are generally available. For unattended runs, they replace --allow-all-tools

On 26 October 2026 GitHub made assisted permissions generally available in Copilot CLI, the Copilot app and VS Code. Every time the agent wants to run a command, touch a path or open a URL, a language model decides whether the request is clearly safe. If it is, the agent carries on. If not, you get the prompt, as before.

That’s the interactive story, and it’s the less interesting half. The more useful half is a flag for runs with nobody at the keyboard, because it changes what a CI job running Copilot CLI should be allowed to do by default.

What GitHub has shipped

According to the GitHub changelog , it’s a permission mode. In the CLI you run /permissions and pick assisted. In the Copilot app it’s under Tool permissions in the mode picker, and in VS Code it’s in the permissions picker.

The CLI docs give the shortcuts. /permissions assisted turns it on, /permissions manual goes back to prompting, /permissions show prints the current mode, and /reset-allowed-tools resets to manual. To make it the starting mode, set defaultPermissionMode to "assisted" in your user settings file. The command reference puts that at ~/.copilot/settings.json, or $COPILOT_HOME/settings.json if you’ve set the variable.

Two things stay as they were. Read-only operations (searching, reading files, read-only shell commands) are already allowed automatically, subject to policy. And deny rules still win: the docs say they take precedence over allow rules even with --allow-all set or an approval saved. Assisted mode only has a say on requests that your existing permissions don’t already settle.

What GitHub doesn’t tell you is how the reviewer decides. The changelog and docs say “clearly safe” requests proceed and don’t define it. They don’t name the model, give an accuracy figure or list request types that are never auto-approved. The changelog also doesn’t say which Copilot plans include the feature. Treat the classifier as a black box that reduces prompts. It isn’t a boundary you can reason about. That matters for a CI job, where nobody is around to notice a bad call. A deny rule has a written meaning and a model’s judgement doesn’t, so anything you must never allow belongs in a deny rule, not in the reviewer’s hands.

The non-interactive flag

For scripts, the docs describe --assisted-approval, or COPILOT_ASSISTED_APPROVAL=true in the environment when you can’t easily change the command line. The programmatic reference has the one example:

copilot -p "Fix the failing tests" --assisted-approval

The behaviour is different from the interactive mode in one important way. There’s nobody to ask, so a request the reviewer won’t wave through is denied, and the reason goes back to Copilot so it can try another approach. The agent isn’t stopped, it’s redirected. That’s the same shape as Claude Code’s auto mode in claude -p, covered in Teach Claude Code’s auto mode about your infrastructure .

The flag is valid only for non-interactive runs. Start an interactive session with it and the CLI exits with an error.

Before this, a headless job that needed to edit files or run tests had two choices: pre-approve specific tools with --allow-tool, or pass --allow-all-tools and accept that the agent could run anything. The docs recommend the allow-all options only in isolated environments. Assisted approval is a third option between them.

What it overrides and what it doesn’t

This is the part to read before you edit a workflow. According to the programmatic reference:

• When assisted permissions are successfully enabled, they override --allow-all-tools. Tool requests go through the review instead of blanket approval.
• --allow-all-paths and --allow-all-urls are unaffected, including when they arrive through --allow-all or --yolo. File and URL access can stay unrestricted.
• Existing sandbox protections and mandatory approval requirements still apply.

So a job that runs with --allow-all gets a reviewer on tool calls and nothing on paths or URLs. If your worry is an agent reading a secrets file or fetching an arbitrary URL after a prompt injection in a README, the flag doesn’t narrow that. Replace --allow-all with the narrower options if you want the review to be the only door.

When the policy says no

The docs describe a failure mode that matters for CI. If assisted permissions can’t be enabled, for example because enterprise settings block them, the CLI writes a warning to standard error and carries on. It doesn’t cancel a separate --allow-all-tools, so tool requests may then be approved with no review at all.

Read that twice. A job with both flags that runs on a runner under a stricter policy silently falls back to the thing the flag was meant to replace. The log has a warning in it, and nothing fails.

On the admin side, the changelog says enterprise-managed settings can block Allow All while keeping Assisted available, disable Assisted separately, and set the default mode for new sessions. If a default is unavailable or prohibited, new sessions start with manual approval. Developers can choose any other mode the policy allows.

What to do with it

This is opinion, based on the documented behaviour. None of it has been run against a live Copilot CLI.

Drop --allow-all-tools from any unattended job and use the assisted flag alone. Then the policy-block case fails closed: requests that need approval are denied in a non-interactive run, and Copilot often can’t finish the task. A red job is better than a green job that ran unreviewed.

- name: Fix failing tests
  env:
    COPILOT_ASSISTED_APPROVAL: "true"
  run: copilot -p "Fix the failing tests and stop. Do not push."

Authentication is whatever your setup already uses. The point is what’s missing from the step: no --allow-all-tools, no --yolo.

Add explicit deny rules for anything you never want, since the docs say deny rules win over allow rules, even with --allow-all set. The syntax takes a tool kind with an optional pattern in parentheses, so --deny-tool='shell(git push)' blocks pushes and --deny-tool=write blocks every file write. A job that may commit but never push would carry --allow-tool='shell(git:*)' --deny-tool='shell(git push)', which is the docs’ own example.

Keep the job’s token read-only where you can, so a bad approval costs less. And expect denials in the first few runs. Each one tells you whether to add a narrow --allow-tool for a command the job really needs, which is better than asking a classifier to approve it every time.

Assisted approval is a prompt reducer with a model in the loop. It doesn’t replace a sandbox, and in CI the sandbox is the runner. Run the job somewhere disposable first, with a token that can’t do much, and read the stderr of the first run for that warning line.