GitHub Copilot makes assisted permissions generally available in the CLI, VS Code and the Copilot app

GitHub has made assisted permissions generally available in GitHub Copilot, according to an entry in the GitHub changelog dated October 26, 2026. The feature adds a permission mode in which a large language model reviews the actions a Copilot agent wants to take, such as running a shell command, accessing a file system path or fetching a URL, and approves on its own the requests it classifies as clearly safe. Anything the model is not confident about is passed back to the developer for a manual decision, exactly as it would be under the traditional approval flow.

The mode is available in GitHub Copilot CLI, in Visual Studio Code and in the GitHub Copilot app, and it is now open to all users of those surfaces rather than limited to a preview group. GitHub's announcement does not specify which subscription plans include it, and the accompanying documentation does not say whether the safety reviews consume premium requests or how the data sent to the review model is handled. Those gaps matter for teams that will want to enable the mode broadly, and they are discussed further below.

The release addresses one of the most practical frictions of agentic coding tools. An agent working through a multi-step task in a repository can trigger dozens of approval prompts for routine operations like listing files, reading a configuration or running a test suite. Developers facing that volume tend either to click through prompts without reading them or to switch to a blanket "allow all" mode that removes oversight entirely. Assisted permissions is GitHub's attempt at a middle path: routine requests flow through automatically, while the developer's attention is reserved for actions the reviewing model considers uncertain.

··········

HOW THE MODEL-BASED REVIEW DECIDES.

According to GitHub's documentation, assisted permissions does not replace the existing permission system but sits on top of it. Existing rules and human approvals are checked first, so a request that is already allowed by the developer's configured permissions runs without a prompt and without any model review. Only the eligible requests that remain after that check, namely shell commands, path access and URL fetches, are sent to the reviewing model.

The model then assesses whether the requested action is safe "within the authority you gave for the task," in the wording of the documentation. That phrasing is significant, because the review is meant to be contextual rather than a static allowlist: the same command could be reasonable for one task and out of scope for another. If the model is confident, Copilot approves the request automatically. If it is not, the developer sees a standard approval prompt. GitHub does not publish a list of actions that count as clearly safe, and the documentation describes the judgment only in general terms.

The choice of reviewer is handled by Copilot itself. GitHub says Copilot selects the review model, which can differ from the model the developer is using for the conversation. If the selected review model is unavailable, the review can fall back to the session's active model. Developers who bring their own model provider (BYOK) always get reviews from their session's active model. When the safety review is unavailable or cannot evaluate a request, Copilot falls back to normal session permission handling, which in practice means the developer is asked.

··········

THE FOUR PERMISSION MODES COMPARED.

Assisted permissions joins an existing set of approval options. GitHub's documentation describes it as one of three approval modes, alongside manual approval and unconditional approval, while autopilot is documented separately and changes how pending approvals are treated.

........

Mode	How requests are handled	Human prompts
Manual approval	Copilot asks before any action not already allowed; approval can be given once or for the session	Yes, for every new action
Assisted permissions	A review model auto-approves requests it judges safe within the task's authority	Only for requests the model is not confident about
Unconditional approval (allow all)	Broad permission with no model review and no individual prompts	No
Autopilot	Requests that still need approval are denied, and the review's explanation is returned to Copilot	No

........

The autopilot behaviour deserves attention. In autopilot and other non-interactive runs, there is nobody to answer a prompt, so requests that the review does not approve are denied rather than queued. GitHub says the explanation from the review is sent back to Copilot so the agent can try another approach. That design turns the review into a feedback signal for unattended agents rather than a hard stop, which is relevant for teams running Copilot in scripts or CI pipelines.

··········

WHAT THE REVIEW MODEL CANNOT OVERRIDE.

GitHub draws clear boundaries around what the model is allowed to approve. Enterprise deny rules still apply in all cases, so an action an administrator has blocked stays blocked regardless of the model's judgment. Enterprise "ask" rules for shell commands, file reads, file writes and URLs can be satisfied by a model approval, but only when the request falls into the categories eligible for review.

Two classes of request are never reviewed by the model. The first covers other tool calls that enterprise rules require a human to approve. The second covers requests to bypass local sandboxing. Both follow normal session handling, which means the developer is prompted in an interactive session.

The documentation is also candid about the limits of the approach. GitHub warns that "the model can make mistakes and approve dangerous or unintended actions," and states that assisted permissions "is not a substitute for sandboxing or access restrictions." It recommends reviewing the actions Copilot takes and considering a sandbox or isolated environment. In other words, GitHub positions the feature as a way to reduce prompt fatigue, not as a security control in its own right.

··········

HOW TO TURN ON ASSISTED PERMISSIONS IN EACH SURFACE.

The changelog describes a short path in each of the three supported surfaces. In Copilot CLI, developers run the /permissions command and select the assisted option. In the GitHub Copilot app, they open the mode picker, click Tool permissions and select Assisted; the default for new sessions can be changed under Settings, Sessions, Tool permissions. In Visual Studio Code, the option appears in the permissions picker as Assisted permissions. GitHub notes that cloud sessions in the Copilot app do not offer tool permission controls.

The CLI documentation lists the commands available inside an interactive session, taken here from GitHub's docs:

/permissions assisted
/permissions manual
/permissions show
/permissions

The first command enables assisted permissions for the current session, the second returns to manual approval, the third shows the current mode and the last opens a list from which to pick a mode. Unconditional approval remains available through /permissions allow-all or /yolo, and through the --allow-all and --yolo flags. To make assisted the default for new interactive sessions, developers can set defaultPermissionMode to "assisted" in ~/.copilot/settings.json.

For non-interactive runs, GitHub documents a dedicated flag and an environment variable:

copilot -p "Fix the failing tests" --assisted-approval
COPILOT_ASSISTED_APPROVAL=true

A few details in the documentation are easy to miss and can change behaviour in automation. Using --assisted-approval in an interactive session causes an error. The flag overrides --allow-all-tools, but it does not override --allow-all-paths or --allow-all-urls, so scripts that grant broad path or URL access keep that access. If assisted permissions cannot be enabled, the CLI writes a warning to standard error and does not cancel --allow-all-tools, which means a script could silently keep running with unconditional tool approval. GitHub advises checking automated run output for that warning.

··········

WHAT CHANGES FOR ENTERPRISE ADMINISTRATORS.

The general availability release also gives organizations more precise control over which modes developers can use. According to the changelog, administrators can use enterprise-managed settings to block Allow All while keeping Assisted available, or to disable Assisted separately. They can also set the default permission mode for new sessions, and developers remain free to choose any other mode that policy permits. If the configured default is unavailable or prohibited, sessions start with manual approval.

........

Enterprise-managed setting	Effect
permissions.disableBypassPermissionsMode: "disable"	Disables unconditional approval while keeping assisted permissions
permissions.disableAssistedPermissionsMode: true	Disables assisted permissions
permissions.defaultMode	Managed default that takes precedence over a developer's personal default

........

This combination lets an organization remove the riskiest option, unconditional approval, without forcing developers back to answering every prompt by hand. For companies that have hesitated to allow agentic workflows because "allow all" was the only realistic way to get work done, the ability to make assisted the managed default and block the bypass mode is probably the most consequential part of the release.

The timing coincides with a broader expansion of Copilot's agent surfaces. On the same day, GitHub made OpenAI's GPT-6.1 Terra generally available across Copilot, covered in our article on GPT-6.1 Terra's launch, computer use and pricing. Faster and cheaper models make longer autonomous sessions more practical, and longer sessions are exactly where the number of approval prompts becomes a bottleneck.

··········

WHAT IS ESTABLISHED AND WHAT REMAINS OPEN.

The verified facts are clear. Assisted permissions is generally available as of October 26, 2026, in Copilot CLI, Visual Studio Code and the GitHub Copilot app. A model chosen by Copilot reviews shell commands, path access and URL fetches that are not already allowed, approves those it judges safe within the task's authority, and prompts the developer for the rest. Enterprise deny rules always apply, requests to bypass sandboxing are never reviewed by the model, and administrators can block unconditional approval while keeping assisted mode available.

Several practical questions are not answered in GitHub's published material. The announcement does not name the subscription plans that include the feature, the documentation does not state whether each safety review consumes premium requests or adds measurable latency, and GitHub has not described how request data sent to the review model is handled or retained. GitHub also does not publish accuracy figures for the review model, such as how often it approves actions that a human would have rejected, which is the metric that ultimately determines how much oversight the mode preserves.

GitHub's own documentation frames the right way to read the release: the model can make mistakes, and assisted permissions does not replace sandboxing or access restrictions. Teams that adopt it will get fewer interruptions in routine agent work, but the security boundary still has to come from isolated environments, enterprise deny rules and the scope of credentials an agent can reach.

··········

FOLLOW US FOR MORE.

·····

DATA STUDIOS

·····

datastudios.org