The appeal is straightforward: fewer interruptions without handing an AI coding agent the equivalent of a master key. The important distinction is that assisted approval is a model’s judgment—not a guarantee of safety.
How to enable assisted permissions
GitHub gives a different selection route for each client:
| Client | Enable assisted permissions |
|---|---|
| GitHub Copilot CLI | Run /permissions, then select assisted. |
| GitHub Copilot app | Open the mode picker, choose Tool permissions, then Assisted. |
| Visual Studio Code | Open the permissions picker and select Assisted permissions. |
These are the client-specific controls identified in GitHub’s general-availability announcement.
For CLI users, GitHub’s documentation also provides /permissions show to inspect the current mode and /permissions manual to return to manual approval. In the Copilot app, selecting Assisted through the mode menu changes the current session and saves the default for new local sessions; cloud sessions do not expose these controls.
Fewer prompts do not mean unrestricted access
GitHub’s documentation says existing permissions are considered before model review, and enterprise deny rules remain applicable. Already-permitted actions can proceed without another review. Crucially, GitHub warns that the model can approve dangerous or unintended actions: assisted permissions does not replace sandboxing or access restrictions.
That makes this a workflow trade-off rather than a security boundary. Our assessment: reducing repetitive prompts can be useful, but the decision to allow automatic approval should remain separate from the decision about what files, credentials, and systems an agent can reach.
Enterprise administrators get separate switches
GitHub’s enterprise-managed settings distinguish between blocking broad approval and blocking assisted approval:
permissions.disableBypassPermissionsModeset to"disable"prevents bypass or allow-all operation without disabling Assisted.permissions.disableAssistedPermissionsModeset totruedisables Assisted separately; it does not disable bypass.permissions.defaultModeaccepts"manual","assisted", or"allow-all"for new sessions.
A default is not a lock. Developers can make another permitted session-level choice, and an unavailable or policy-blocked default falls back to manual approval. In Copilot CLI, the managed default takes precedence over the user’s preference.
The practical implication is worth spelling out: an organization seeking manual-only operation should not assume that disabling just one automatic-approval mode also disables the other.
Automation has a different approval outcome
For unattended CLI execution, GitHub documents --assisted-approval. Requests that still need human approval are denied rather than left waiting. There is also a significant flag interaction: assisted approval does not cancel --allow-all-paths or --allow-all-urls, so combining it with --allow-all can leave those categories unrestricted.
For developers and administrators, that is the takeaway: assisted permissions offers a middle ground between repeated confirmation and blanket approval—but its value depends on the surrounding restrictions. Fewer permission dialogs should mean less interruption, not less attention to what the agent actually does.
References
- GitHub Copilot assisted permissions generally available GitHub Changelog · 2026-10-26T22:31:30+00:00
- Allowing safe commands to run without manual approval - GitHub Docs docs.github.com
- Enterprise managed settings - GitHub Enterprise Cloud Docs docs.github.com