GitHub Copilot Assisted Permissions: How It Works and What to Check

GitHub made Copilot assisted permissions generally available on October 26 in the CLI, Copilot app and Visual Studio Code. A model reviews eligible requests to run commands, access paths or open URLs, allowing requests it judges clearly safe to proceed while leaving others for approval.

The GA announcement puts an intermediate option between manually approving actions and granting broad, unconditional access. For developers working through long tasks, the attraction is fewer interruptions without choosing Allow All.

How to enable Copilot assisted permissions

In Copilot CLI, run /permissions and choose assisted. In the Copilot app, open the mode picker, select Tool permissions, then Assisted. In VS Code, choose Assisted permissions from the permissions picker.

Enterprise administrators can block Allow All without blocking Assisted, or disable Assisted separately. They can also choose the default permission mode for new sessions. A developer can still select another mode if policy permits it; an unavailable or prohibited default falls back to manual approval.

That last distinction matters. Choosing an organisation-wide default and enforcing a restriction are different decisions. A default is a starting point, rather than proof that every session is using the same approval policy.

What the model review can and cannot do

GitHub’s assisted-permissions documentation says existing rules and approvals are considered before eligible unresolved requests reach the reviewer. The review model can differ from the model handling the coding conversation.

GitHub explicitly warns that this model can approve dangerous or unintended actions. Assisted permissions does not replace sandboxing or access restrictions. It is a judgment about a proposed action, not a guarantee about everything the action might cause.

For example, a command that looks routine can invoke project scripts with effects that deserve a separate boundary. Teams should decide which files, services and credentials the environment can reach before deciding how much approval friction to remove.

For non-interactive CLI runs, --assisted-approval denies requests still needing a person. Combining it with --allow-all does not necessarily narrow path and URL permissions, which can remain broad. Inspect the effective permissions before running unattended.

An enterprise policy detail needs clarification

Two current GitHub documentation pages describe enterprise ask rules differently.

The assisted-permissions guide says eligible CLI requests involving shell commands, file access and URLs can satisfy an enterprise ask rule through model approval. The enterprise-managed settings reference instead says a managed ask rule requires fresh human approval and cannot be satisfied by auto-approval shortcuts.

Those descriptions do not establish one consistent rule for administrators to rely on. This is a documentation discrepancy, not evidence of a demonstrated exploit or a claim that Copilot ignores enterprise policy. Before treating ask as a mandatory human checkpoint, verify the behaviour in the client and configuration your team actually uses.

The settings reference also separates two controls: permissions.disableBypassPermissionsMode blocks bypass behaviour, while permissions.disableAssistedPermissionsMode disables assisted permissions. Setting the latter does not itself disable bypass mode.

What changes in a developer workflow

The useful outcome is fewer low-value approval prompts while important decisions still receive attention. That outcome needs to be measured in actual work: which actions proceed automatically, which still pause, and whether the remaining prompts are understandable enough for a developer to judge.

An approval system that asks less can be easier to supervise. But the saved attention only helps if the environment still limits the consequences of a mistaken decision. The next step for teams is to define those boundaries clearly, then evaluate whether assisted permissions makes work smoother inside them.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain developer tools and product changes clearly, without turning the important limitations into footnotes.

Book a 30-minute call.