GitHub Copilot's Assisted Permissions Let a Model Click Yes for You. Build the Floor First.

What the new approval mode checks, what it never sees, and the CI warning that can turn it back into unreviewed approvals

A coding agent asks the same question dozens of times an hour. May I run this test? May I read that file? May I fetch this URL?

The first few prompts get careful attention. By the fortieth, it is easy to start pressing Enter without reading, which is the worst of both worlds: all the friction of approval and none of the safety.

On October 26, GitHub shipped its answer. Assisted permissions are now generally available in Copilot CLI, the Copilot app and VS Code. When Copilot wants to run a command, touch a file path or open a URL, a language model reviews the request first. In GitHub's words: "Requests classified as clearly safe automatically proceed. Other requests require your approval."

That sounds like a smarter yes button. It is something narrower, and the difference decides whether it makes you safer or just quieter.

Here is the idea this piece is built on: assisted approval is a filter that sits on top of your rules, not a replacement for them. Your rules are the floor. The model only decides the gray zone above it. If you never built the floor, the model is deciding everything, and GitHub's own docs tell you not to let it.

What actually shipped

Copilot now has a few permission modes. The short version:

Manual is the classic behavior. Anything your rules have not already allowed asks you first.
Allow all (also reachable as --allow-all or --yolo in the CLI) runs everything without asking. Fast, and only sensible in a throwaway environment.
Assisted is the new middle. A model reviews each eligible request, approves the ones it is confident about, and hands the rest back to you.

You turn it on per session in Copilot CLI with /permissions assisted, check it with /permissions show, and go back with /permissions manual. To make it the default for new sessions, set "defaultPermissionMode": "assisted" in ~/.copilot/settings.json. In the Copilot app it sits under the mode menu as Tool permissions, then Assisted. All of this comes from GitHub's page on allowing safe commands to run without manual approval, which is the document worth reading before you flip anything.

How the check works, in plain words

Think of a building with a security desk. Some people have a badge, and they walk straight in. Some names are on a do-not-admit list, and they never get past the door. Everyone else stops at the desk, where a guard decides whether to wave them through or call you down.

Assisted permissions is the guard. It is not the badge system and it is not the do-not-admit list.

GitHub's docs spell out the order:

Your existing rules and earlier approvals go first. If a request is already allowed, it runs with no model review at all.
Enterprise deny rules still apply. The model cannot approve something an admin has blocked.
Everything left goes to the model. If it is confident the request is safe "within the authority you gave for the task," Copilot runs it. If not, you get the normal prompt.

The eligible requests are shell commands, file reads and writes, and URLs. Two kinds of request skip the review entirely: tool calls that enterprise rules say a human must approve, and requests to bypass local sandboxing. Those follow the session's normal handling, which is good. A model should not be the one deciding whether to turn off the sandbox.

A few details matter more than they look:

The reviewer may not be your chat model. GitHub says the review model can differ from the one you are talking to. If it is unavailable, the session's active model does the review. If you bring your own model provider, your session model always does it.
When the reviewer can't decide, you decide. If the review is unavailable or can't evaluate a request, the request falls back to normal permission handling.
Unattended runs fail closed. In Autopilot and non-interactive runs, anything that still needs approval gets denied, and the review's explanation goes back to Copilot so it can try a different approach.

That last behavior is the right default. A run that nobody is watching should not be guessing.

What the model never sees

Notice what this design implies. Your allow rules short-circuit the review. So if you allowed shell(*) months ago to stop the nagging, assisted mode changes nothing for shell. Those commands were never going to reach the guard.

The reverse also holds. If you never wrote a single deny rule, the model is the only thing standing between your agent and git push --force. It might catch it. GitHub's docs are blunt that it might not: the model "can make mistakes and approve dangerous or unintended actions," and assisted permissions "is not a substitute for sandboxing or access restrictions."

VS Code's approvals documentation says the same thing in its own words: assisted permissions "reduces approval interruptions but does not replace your judgment. The model-based risk assessment can make mistakes."

Two vendors' docs telling you not to trust the feature alone is worth taking seriously.

The CI trap

Here is the detail most people will miss, and it lives in a single paragraph of the GitHub docs.

For non-interactive runs (scripts, CI jobs), you enable the reviewer with a flag:

copilot -p "fix the failing unit test" --assisted-approval

or with the environment variable COPILOT_ASSISTED_APPROVAL=true.

Two rules come with it. First, --assisted-approval takes precedence over --allow-all-tools, but it does not change --allow-all-paths or --allow-all-urls. If your script passes those, file and URL access stay wide open no matter what the reviewer thinks.

Second, and worse: if assisted mode can't be enabled, Copilot writes a warning to stderr, and --allow-all-tools "may still approve requests without review." GitHub's own advice is to check automated run output for that warning.

Put plainly: a pipeline written as "assisted approval, with allow-all-tools as a fallback" can fall back to unreviewed tool approvals on the day the reviewer fails to start. The only signal is a line on stderr, and nobody is watching CI logs scroll by. The job goes green, and the review never happened. (Paths and URLs stay open only if the script also passed their allow-all flags.)

Put this into practice

Build the floor first, then hire the guard.

1. Write the do-not-admit list. In Copilot CLI, --deny-tool blocks a tool outright. A guide to the CLI's permission model gives examples like --deny-tool='shell(git push)' and notes that deny rules beat both --allow-tool and --allow-all-tools. Start with the actions you would never want an agent to take unasked: pushes, deploys, package publishes, anything that touches production credentials. --deny-url does the same for domains.

In VS Code, terminal rules live in chat.tools.terminal.autoApprove. Know one quirk: a false rule there means "ask first," not "block," per the VS Code docs. VS Code also calls its own terminal auto-approval "a best-effort convenience, not a security boundary."

2. Narrow where the agent can reach. By default the CLI covers the current directory, its subdirectories and the system temp folder (per the same guide). Prefer --add-dir for specific extra folders over --allow-all-paths. If you can, run the agent in a sandbox or a disposable container; that is the one control a persuasive prompt cannot talk its way past.

3. Then turn on the guard. Inside a session:

/permissions assisted
/permissions show

Watch what it auto-approves for a day. If it waves through something you would have stopped, add a deny rule for it rather than hoping the model learns.

4. Make CI fail loudly. Do not combine --assisted-approval with --allow-all-tools as a fallback. If you must keep both, make the job fail when the assisted-mode warning appears on stderr, because GitHub says that is the moment unreviewed approvals can slip through. And drop --allow-all-paths and --allow-all-urls from scripts unless the job truly needs them.

5. If you run a team, set the policy floor. Enterprise managed settings include permissions.disableBypassPermissionsMode: "disable" to remove unconditional approval while keeping assisted mode, permissions.disableAssistedPermissionsMode: true to turn assisted off, and permissions.defaultMode to pick the default for new sessions. The changelog adds that if your default mode is prohibited by policy, the session starts with manual approval. That is the safe failure, and it is the one you want.

What to expect once this is in place: far fewer prompts for read-only and routine commands, the same hard stops on the things you listed, and the occasional prompt you did not expect. That last one is the guard doing its job.

Honest limitations

GitHub has not published how the reviewer decides. The changelog does not name the model or define "clearly safe," and the docs say only that it judges safety within the authority you gave for the task. You are trusting a classifier you cannot inspect.

The docs do not describe an audit log of what the reviewer approved, or whether the reviews cost anything against your plan. If you need to show an auditor why a command ran, assisted mode does not obviously give you that today.

Prompt injection is not addressed. An agent that reads a hostile README or issue can be steered into requesting something that looks harmless in isolation. A reviewer that sees one request at a time may approve it.

The surfaces also disagree on maturity. The changelog calls it generally available, while VS Code's approvals page still labels assisted permissions experimental and says it needs Folder isolation (the agent works directly in your project folder) and does not work in VS Code's Local sessions. The same page says sessions using Worktree isolation (the agent works in a separate git checkout) always run in Allow all, so the assisted guard is not there at all in that setup. Check what your editor version actually supports.

And none of this applies to cloud sessions in the Copilot app, where GitHub says tool permission controls are not available.

The yes that matters

Assisted permissions is a good feature with a narrow job. It removes the prompts you were rubber-stamping anyway and leaves you the ones worth reading.

It cannot write your deny list, choose your sandbox or notice that your CI script fell back to unreviewed approvals. Those were always your job. The new mode just makes it more obvious which yes came from a person and which came from a model.

Build the floor this week. Then let the guard have the desk.

Sources: GitHub changelog, Oct 26, 2026 · GitHub Docs: allowing safe commands · VS Code: approvals · Dev Leader: Copilot CLI permission model, July 21, 2026. Docs read October 27, 2026.