No More Nodding at Every Step — and No Blanket Approval Either: Copilot Assisted Permissions Goes GA

__MEDIA_1__

Anyone who works with Copilot knows both extremes. One is having to nod at every single move: ten minutes into a task, you have already dismissed twenty confirmation dialogs. The other is turning on Allow All to save trouble, then sitting there uneasily while the agent races ahead, unsure what it just deleted, changed, or connected to. On 26 October 2026, GitHub made a third path generally available: assisted permissions, covering GitHub Copilot CLI, the GitHub Copilot app, and Visual Studio Code. Its logic is simple, and worth taking seriously: not every request needs a human approval, and not every request can go without one — the middle part gets screened by a model first.

GitHub's changelog entry is only a few sentences, but every sentence matters. When Copilot requests permission to run a command, access a file system path, or open a URL, a large language model evaluates the request. Requests classified as clearly safe automatically proceed. Other requests require your approval. Note the wording: the model evaluates the "request," not the outcome; and it lets through the part that is "clearly safe," not the part that is "probably fine." That sense of proportion is the whole point of assisted mode — it does not switch approvals off for you, it removes the approvals that clearly did not need your attention.

Each of the three clients has its own way of turning it on, and GitHub spells out each one in the announcement. In Copilot CLI, run /permissions, then select assisted. In the Copilot app, open the mode picker, click Tool permissions, then select Assisted. In VS Code, open the permissions picker, then select Assisted permissions. The fact that the paths are written out this precisely tells you GitHub does not want users hunting through deep settings: this is a session-level working mode, not an experimental switch buried in configuration. Select it, and the approval rhythm of your current session changes; do not select it, and everything stays as it was.

The accompanying documentation explains the three modes more clearly. Manual approval gives the most control and the most prompts: any action not already allowed, such as running a non-read-only command, editing a file, or accessing a URL, needs your approval, and you can approve it once or for the rest of the session. Unconditional approval — the --allow-all or /yolo option in the CLI — goes to the other extreme: Copilot gets broad permission to use tools, paths, and URLs without a model safety review or individual approval prompts, and your oversight of individual actions disappears. Assisted permissions sits in between: a model reviews eligible requests, automatically approves those it judges safe, and sends the rest back to you. It reduces the number of prompts, not the supervision itself.

That "middle" is not a slogan; it has a specific execution order. The documentation says that when assisted permissions is enabled, existing rules and human approvals are evaluated before a model review. Requests already allowed by your permissions run without a prompt or a model review. Only requests that are not already resolved and are eligible for review — to run a command, access a path, or fetch a URL — go to the model, which assesses whether the action is safe and within the authority you gave for the task. If the model is confident the request is safe, Copilot approves it automatically and continues. If the model is not confident, Copilot asks for your approval, just as it would with manual approval. If a safety review is unavailable or cannot evaluate a request, the request follows the session's normal permission handling, rather than being approved by default. That "if we cannot evaluate it, we do not approve it" default is an important safety line.

For enterprise administrators, the biggest change in general availability may not be one more option for individual users, but a set of switches that can be controlled separately. The announcement states that enterprise administrators can use enterprise-managed settings to block Allow All while keeping Assisted available, or disable Assisted separately. The documentation gives the corresponding setting names: disabling unconditional approval with permissions.disableBypassPermissionsMode does not disable assisted permissions, while permissions.disableAssistedPermissionsMode disables assisted permissions on its own. In other words, "no blanket approval" and "assisted approval allowed" are no longer an all-or-nothing pair; administrators can ban only the most dangerous tier and leave the middle tier for teams.

Administrators can also choose the default permission mode for new sessions, while developers can still select another mode permitted by policy. If the administrator's default is unavailable or prohibited by policy, the session starts with manual approval, rather than quietly falling back to something more permissive. The CLI configuration details confirm this: users can set defaultPermissionMode to "assisted" in ~/.copilot/settings.json as their preference for new interactive sessions, but an administrator's permissions.defaultMode takes precedence over the user preference; if the selected default is unavailable or blocked by policy, the CLI starts with manual approval and explains why. The hierarchy of defaults follows the same principle as a chain of command: higher-level rules cannot be quietly overridden by lower levels.

There is another detail whose weight only becomes obvious once you have actually run automated Copilot tasks: in autopilot mode and non-interactive runs, requests that still require your approval are denied instead of waiting for you. The documentation says that when the safety review requires approval, its explanation is passed back to Copilot so it can try a different approach. The CLI has a matching switch for non-interactive use, --assisted-approval, and an environment variable, COPILOT_ASSISTED_APPROVAL, designed for situations where nobody is sitting at a terminal, such as CI/CD workflows, scheduled jobs, and batch scripts. Without that switch, you face two unpleasant options: give nothing, and the task often cannot finish; or give --allow-all-tools, and hand over tool permissions wholesale. Assisted approval is valuable here precisely because it lets unattended work move forward without running completely exposed.

But the documentation also contains a warning that must be read in full, and it matters more than the announcement itself. GitHub states plainly: assisted permissions reduces how often you are prompted, but it does not remove your responsibility for what Copilot does; the model can make mistakes and approve dangerous or unintended actions; this feature is not a substitute for sandboxing or access restrictions; and, as with any automatic approval option, you should review the actions Copilot takes, and consider running it in a sandbox or other isolated environment. That passage pins down what assisted permissions is: an efficiency tool, not a safety guarantee. Treating it as "the model already reviewed it, so I do not need to look" is a misuse.

That warning leads to a subtler point: the meaning of enterprise "ask" rules changes. The documentation says that in Copilot CLI, enterprise ask rules for shell commands, file reads, file writes, and URLs can be satisfied by model approval when the request is eligible for review. In other words, "ask" no longer necessarily means "a human will definitely be prompted." At the same time, enterprise deny rules still apply, and assisted permissions does not review other tool calls that enterprise rules require you to approve, or requests to bypass local sandboxing — those remain subject to the session's normal permission handling. When teams write policy, they have to think about these two categories separately: which asks can be delegated to model approval, and which must always stay with a person.

There is another combination that is easy to get wrong, and the documentation flags it with its own warning. When --assisted-approval is successfully enabled in a non-interactive run, it takes precedence over --allow-all-tools, but it does not change --allow-all-paths or --allow-all-urls. If you also pass --allow-all or --yolo, path and URL access can still be unrestricted even though tool requests go through assisted approval. Worse, if assisted permissions cannot be turned on — because your enterprise settings block it, for example — the CLI only writes a warning to standard error; it does not cancel a separate --allow-all-tools option you supplied, so tool requests may still be approved without a safety review. For anyone running automated tasks, checking the warnings in standard error matters as much as checking whether the task finished.

So who should actually turn on assisted permissions? The answer depends on how you work, not on your job title. If you are doing well-bounded work in a familiar project, where changes are reviewed by someone and the environment itself is isolated, assisted permissions can save you a lot of repetitive confirmations and leave your attention for the requests that are genuinely worth looking at. If you are working with production data, credentials for external systems, or a codebase you do not know well yet, the annoyance of manual approval is precisely the protection: those prompts are not noise, they are your last chance to stop an action before it happens. Assisted permissions removes the "clearly safe" part, and that only works if you and your team share an understanding of what "clearly" means; if your shared understanding is "if it runs, it is safe," this mode will only make danger move faster.

For team leads, the real significance of general availability is that policy can now be written more precisely. Many teams previously had only two choices: endure the friction of manual approval for everyone, or tacitly allow some people to use Allow All and hope nothing went wrong. Now policy can be written in three tiers: assisted approval as the default, unconditional approval banned, and particularly high-risk scenarios tightened separately. The policy itself is not hard to write; the hard part is the accompanying habits: regularly checking what Copilot actually did, reviewing automatically approved actions for anomalies, and making sure new team members understand that "the model approved it" does not mean "a human reviewed it." The tool gives you a middle tier; if management habits are still stuck in two-tier thinking, half the benefit of the middle tier will be wasted.

Seen in a larger picture, assisted permissions is a provisional answer to a question the agent era cannot avoid: when an agent can initiate dozens of tool calls per minute, people cannot approve each one individually, and cannot let go entirely either. GitHub's answer is layered: rules first, model screening second, humans as the final gatekeeper. This answer is imperfect — the model can make mistakes, the review itself can be unavailable, and the review model may not even be the same model you are talking to — but at least it states clearly who is responsible for what: rules set the floor, the model does the screening, and people carry the final responsibility. That honest triangle is more useful than pretending the problem does not exist.

The model used for review deserves a paragraph of its own. The documentation notes that Copilot selects the model used for the safety review, which can differ from the model you selected for your conversation; if the selected review model is unavailable, the review can use your session's active model instead; and if you use your own model provider, the review uses your session's active model. That means "who is approving" is not a fixed answer; it can change with model availability. For ordinary users, this does not affect daily use; but for teams that need to take approval records to an audit, it matters that the reviewer's identity is itself a variable, and audits should not assume the same model was gatekeeping every time.

The boundaries between sessions are equally easy to overlook. The documentation says that selecting assisted permissions in the app for the current session also saves it as the default for new local sessions, but does not change other existing sessions; to change only the current session without changing the default, use /permissions assisted, and to change the default without changing the current session, change it in Settings. The CLI has a similar distinction: changing the mode inside a session affects only that session, while editing the configuration file affects future new sessions. These distinctions sound trivial, but in practice they matter a lot: thinking you have "turned on assisted permissions" may mean you only turned it on for one session, and thinking you are "just trying it out" may have already changed your default. After every change, checking the current mode with /permissions show is a habit worth forming.

Placed in the wider evolution of Copilot, assisted permissions has a clear position. Around October 2026 GitHub pushed a dense series of Copilot changes, from multi-model routing to cross-repository collaboration, all aimed at letting agents take on longer, more complex tasks. The longer the task, the heavier the approval burden, and manual confirmation of every step quickly becomes a bottleneck. Assisted permissions moves from "optional" to "worth considering by default" in that context: not to make users think less, but to focus their attention where judgment is genuinely needed. An agent that needs a human nod for every step is still a tool that must be watched full-time; an agent that never asks anyone is an uncontrolled executor. Assisted permissions tries to find a balance between the two that can be used long-term.

Whether that balance holds ultimately depends on the quality of model review, and GitHub gives no quantitative commitment on that point. The announcement does not state the review's accuracy, its false-approval rate, or how the review model is trained and evaluated. The documentation only says the model judges whether a request is safe and within the authority given for the task, approving automatically when confident and asking a human when not. Not giving numbers is honest in one sense — review quality is genuinely hard to summarize in a single figure, and performance will vary a lot across tasks and codebases — but it also means users and teams cannot treat assisted permissions as a verified security control, only as an efficiency optimization, with their own reviews, sandboxes, and permission rules filling in the security side.

There is also a practical limitation: assisted permissions currently covers only three clients. The announcement explicitly lists Copilot CLI, the Copilot app, and VS Code, and does not mention other IDEs or cloud agents. If you regularly switch between clients, do not assume assisted permissions is available everywhere or behaves the same everywhere. In cross-client workflows, approval modes are likely to be inconsistent: one client goes through model review, another is still on manual confirmation. When teams write runbooks, they should spell this out client by client, rather than saying vaguely "we have turned on assisted permissions." A vague statement will almost certainly mislead people during audits and troubleshooting.

At bottom, assisted permissions solves the problem of "too many prompts," not the problem of "judgment is hard." Prompts become fewer, but your judgment does not become less — it is simply concentrated where it is most worth exercising. If you find that after turning on assisted permissions you actually look less at what Copilot did, the tool is working against you: it saved your attention, and you did not spend the saved attention on review. A tool can only change the number of prompts; the quality of judgment remains, always, a human responsibility.

Finally, a practical getting-started suggestion you can follow directly. First turn on assisted permissions in a single session, run familiar tasks for a day or two, and watch what it approves automatically and whether it approves anything you would have wanted it to ask about first. Only then set it as the default for new sessions. Enterprise users should first confirm two things with their administrator: whether Allow All has been banned, and whether assisted permissions has been separately disabled. If you run CI or scheduled tasks, use --assisted-approval instead of --allow-all-tools, and treat warnings in standard error output as a checklist item. Only after doing these things will assisted permissions actually be the "saves trouble without losing control" mode you expect; otherwise, it is just another way to let your guard down.