GitHub Copilot assisted permissions: what admins should set

GitHub made assisted permissions generally available in Copilot CLI, the GitHub Copilot app and Visual Studio Code on October 26, 2026. In this mode, a large language model reviews each permission request to run a command, touch a file path or open a URL, approves the ones it judges safe, and asks you about the rest. If you manage Copilot for a team, the decision now is which permission mode new sessions start in, and whether to block Allow All while keeping Assisted available.

The catch is that Assisted cuts prompts by moving some approvals from a person to a model. GitHub's own documentation says the model "can make mistakes and approve dangerous or unintended actions" and that the feature "is not a substitute for sandboxing or access restrictions." Two GitHub documentation pages also describe managed ask rules differently, so test that boundary before you count on it.

What are GitHub Copilot assisted permissions?

Assisted permissions are a middle setting between approving every action yourself and letting Copilot run anything. GitHub's documentation on allowing safe commands lists three options:

Scroll sideways to see all 3 columns.

Mode	What happens to a request that isn't already allowed	Prompts
Manual approval	You approve it once or for the session	Most
Assisted permissions	A model approves it if it judges it safe; otherwise you are asked	Fewer
Unconditional approval (Allow All, --allow-all or --yolo in the CLI)	It runs with no model review	None

In every mode, deny rules and enterprise restrictions still apply, and requests your rules already allow run without a prompt or a model review. GitHub's changelog entry puts it simply: "Requests classified as clearly safe automatically proceed. Other requests require your approval."

How the safety review decides

Copilot checks your existing rules and earlier approvals first. Only requests that are still open go to the model, which judges whether the action is safe and within the authority you gave for the task. A confident "safe" means Copilot proceeds without asking. Anything else becomes a normal prompt.

A few details from the documentation matter for planning:

• The review model is GitHub's choice. It "can differ from the model you selected for your conversation." If you bring your own model provider, the review uses your session's active model.
• Some requests are never reviewed. Assisted permissions doesn't review other tool calls that enterprise rules require you to approve, or requests to bypass local sandboxing.
• Failures fall back to normal handling. If the review is unavailable or can't evaluate a request, the request goes through the session's usual permission flow.
• Unattended runs deny instead of asking. In autopilot mode and non-interactive runs, anything that would need your approval is denied, and the explanation goes back to Copilot so it can try another approach.
• Cloud sessions are excluded in the app. The app's docs say tool permission controls "are not available for cloud sessions."

Which enterprise settings control assisted permissions?

Three keys in enterprise-managed settings decide what developers can pick:

• permissions.disableBypassPermissionsMode: "disable" blocks Allow All. In the CLI, --yolo, --allow-all and the individual --allow-all-tools, --allow-all-paths and --allow-all-urls options stop working, and /yolo is blocked. In VS Code, the global auto-approve setting is turned off. In the app, sessions can't use Approve all. It does not block Assisted, and the most restrictive value across policy layers wins.
• permissions.disableAssistedPermissionsMode: true turns Assisted off. It does not block Allow All.
• permissions.defaultMode sets "manual", "assisted" or "allow-all" as the starting mode for new sessions. It's a default, not a lock. Developers can still choose any mode that policy allows, and a blocked default falls back to manual approval. In the CLI, it overrides a developer's own defaultPermissionMode in ~/.copilot/settings.json.

If you configure nothing, the documentation says new CLI sessions "can start in manual or assisted mode." Ask developers to run /permissions show instead of assuming which one they got.

Do managed ask rules still force a prompt?

Two GitHub documentation pages don't agree on this, so test it yourself. The safe-commands page says: "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." The enterprise-managed settings page says a managed ask rule "can't be satisfied by bypass mode..., an auto-approval setting, a hook or other approval shortcut."

If your policy uses ask rules for sensitive commands or paths, such as deploy scripts or a secrets directory, those rules may be the only thing between Assisted and an action you want a person to see. Until GitHub reconciles the two pages, check the actual behavior in the CLI before you set Assisted as the default.

The CI flag that can fall back to unreviewed tool approvals

For non-interactive runs, the CLI accepts --assisted-approval (or COPILOT_ASSISTED_APPROVAL=true). It approves what the review judges safe and denies everything else. The documentation gives two warnings worth copying into your pipeline notes:

• It takes precedence over --allow-all-tools, but it "does not change --allow-all-paths or --allow-all-urls." Combined with --allow-all, path and URL access can stay unrestricted.
• If Assisted can't be turned on, for example because enterprise settings block it, the CLI writes a warning to standard error and "does not cancel a separate --allow-all-tools option," so tool requests "may still be approved without a safety review."

If an existing job passes --allow-all-tools and you add --assisted-approval as a safety upgrade, a policy change can remove the upgrade, leaving only a warning on standard error. Remove --allow-all-tools from the command, or fail the job when that warning shows up.

Why it matters for teams rolling out coding agents

BaristaLabs interpretation: the value here is fewer interruptions without handing out blanket permission. GitHub's docs say prompts slow you down most at the start of a session, and the alternative they name is unconditional permission. A policy that blocks Allow All and offers Assisted keeps either a model review or a person on every request your rules do not already settle, which is a better trade than a team quietly running --yolo. It doesn't replace your sandbox, and the review model can be wrong, so keep deny rules and tested local sandboxing in place.

If you already ran the JetBrains assisted approvals preview, keep the boundary tests you wrote for it. The same questions apply to the CLI, the app and VS Code.

A first rollout to try

BaristaLabs recommendation: for one pilot group, set disableBypassPermissionsMode to "disable" and defaultMode to "assisted", and leave Assisted enabled. Then, in the CLI:

1. Run /permissions show in a new session to confirm the mode.
2. Trigger one command covered by a managed ask rule and record whether you are prompted or the model approves it.
3. Try --yolo and confirm it has no effect.
4. Run one CI job with --assisted-approval and no --allow-all flags, and check standard error for the fallback warning.

If step 2 shows model approval for an action you need a person to see, move that action to a deny rule or keep defaultMode at "manual" for that group. Validate the settings file with the managed settings validator before you widen the rollout, and record what you decided the way you would for any approval queue in front of an agent. For help scoping the pilot, see BaristaLabs AI consulting.

Sources and scope

• GitHub Changelog, "GitHub Copilot assisted permissions generally available", October 26, 2026.
• GitHub Docs, "Allowing safe commands to run without manual approval", retrieved October 27, 2026.
• GitHub Docs, "Enterprise managed settings", permissions section, retrieved October 27, 2026.

These sources don't say which model performs the safety review, how accurate it is, or how often it approves requests. BaristaLabs hasn't measured that. The ask-rule behavior above is quoted from two GitHub pages that differ, not from a test.