GitHub Copilot Assisted Permissions: Setup and Safety Limits

GitHub made Assisted permissions generally available on October 26, 2026, for GitHub Copilot CLI, the Copilot app and Visual Studio Code. Instead of asking a developer to approve every eligible command, file-path or URL request, Copilot asks a language model to judge whether the action is safe in the context of the task. Clearly safe requests can proceed automatically; uncertain ones still need human approval in interactive sessions. The feature aims to reduce repetitive prompts without giving an agent unrestricted tool access.

What changed—and what did not

Assisted is a permission-handling mode, not a new coding model or a guarantee that commands are harmless. GitHub's documentation says existing permission rules and human approvals are evaluated before a model review. Requests already allowed by policy can run without review, while enterprise deny rules still block matching actions. The model reviews only eligible unresolved requests; it does not review every tool invocation or a request to bypass local sandboxing. When the review cannot evaluate a request, normal session permission handling applies.

Manual vs Assisted vs Allow All

The practical distinction is oversight. Assisted may be convenient when an agent repeatedly inspects a repository or runs routine commands, but a model can misclassify an action. A production deployment, credential change or destructive operation still deserves restrictive permissions and a separate review process. The table describes permission behavior, not a verified security benchmark or a promise that one mode prevents incidents.

How to enable Assisted permissions

1. In GitHub Copilot CLI, enter /permissions and choose assisted, or use /permissions assisted for the active interactive session.
2. In the GitHub Copilot app, open the mode picker, choose Tool permissions and select Assisted for a local session.
3. In Visual Studio Code, open the permissions picker and choose Assisted permissions.
4. Check the active permission mode and organization policy before running an agent against important files, credentials or production systems.

In the Copilot app, the selected local-session mode can also become the default for new local sessions; it does not retroactively change other sessions. The documented tool-permission controls do not apply to Copilot cloud sessions, and remote-host options depend on the host. In CLI, a personal default can be set with defaultPermissionMode set to assisted, but an administrator's managed default or restrictions take precedence.

Unattended CI and enterprise guardrails

For non-interactive Copilot CLI runs, GitHub documents the --assisted-approval option, or COPILOT_ASSISTED_APPROVAL=true. When the review finds a request safe, it can proceed. If human approval would be needed, that request is denied and Copilot receives an explanation so it may try a different approach. This is not equivalent to approving every action in a CI job. GitHub also warns that combining Assisted with broad path or URL permissions can still leave those access surfaces unrestricted.

A deployment checklist for teams

• Inventory which commands, paths and network destinations the agent actually needs.
• Keep enterprise deny rules and least-privilege access independent of model judgment.
• Test both an ordinary safe request and a sensitive request in a disposable sandbox.
• For unattended runs, confirm that denied requests fail safely and are visible in logs.
• Review the resulting tool actions and revisit policies before allowing production-side effects.

GitHub's documentation explicitly cautions that the reviewing model can make mistakes and approve dangerous or unintended actions. Assisted permissions should therefore be treated as a convenience layer over permissions, sandboxing and monitoring—not a substitute for any of them. Teams should also verify their current client and enterprise settings because availability and policy behavior can differ across environments.