GitHub Copilot’s assisted permissions let an AI approve its commands. How to use them

What GitHub released

On October 26, 2026, GitHub announced that assisted permissions are “now generally available in GitHub Copilot CLI, GitHub Copilot app, and Visual Studio Code.” Its whole description fits in three sentences: “When Copilot requests permission to run a command, access a file system path, or open a URL, a large language model evaluates the request. Requests classified as clearly safe automatically proceed. Other requests require your approval.”

In the CLI it came with version 1.0.104, dated October 27, whose release notes say: “Assisted Permissions are available without enabling experimental mode.” In JetBrains IDEs, the same idea, called assisted approvals, has been in public preview since September 22, and the general release doesn’t name JetBrains.

It’s a third mode between the two Copilot already had. GitHub’s docs describe them:

• Manual approval. Copilot asks before anything that isn’t already allowed, “such as running a command that isn’t read-only, editing a file, or accessing a URL.”
• Assisted permissions. “Copilot uses a model to assess eligible permission requests and automatically approves those it judges to be safe.” You’re asked about the rest.
• Unconditional approval, called Allow all in the CLI and VS Code and Approve all in the Copilot app. Copilot uses tools, paths and URLs “without a model safety review or individual approval prompts.” It’s what --allow-all, --yolo and /yolo turn on in the CLI.

How it decides

Your own rules come first. Requests your permissions already allow run without a prompt or a review, and deny rules and enterprise restrictions still apply. For anything left, the model checks “whether the action is safe and within the authority you gave for the task.” When it’s confident, Copilot carries on without asking. When it isn’t, you get the usual prompt. If the review is unavailable, the request is handled as it would be without one.

Copilot picks the reviewing model, and it “can differ from the model you selected for your conversation.” If you bring your own model provider, the review uses your session’s model.

Three details matter more than they look:

• Admins’ ask rules can be answered by the model. “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.” An organization that wrote ask rules expecting a person to confirm should know that. Deny rules still hold.
• With nobody watching, it says no. In autopilot and non-interactive runs, requests that still need approval are denied, and the reviewer’s explanation goes back to Copilot “so it can try a different approach.”
• It doesn’t review everything. Other tool calls that enterprise rules require you to approve, and requests to bypass local sandboxing, keep their normal prompts. In the Copilot app, cloud sessions have no tool permission controls at all.

How to turn it on, or off

1. In Copilot CLI, enter /permissions assisted. /permissions manual goes back, and /permissions show tells you which mode you’re in. That lasts for the session. For new sessions, set defaultPermissionMode to "assisted" or "manual" in ~/.copilot/settings.json, or use /settings. If it matters to you which mode a session starts in, set it: the configuration reference says that if neither you nor your administrator has set a default, “sessions can start in manual or assisted mode.”
2. In an unattended CLI run, such as CI, add --assisted-approval: copilot -p "Fix the failing tests" --assisted-approval, or set COPILOT_ASSISTED_APPROVAL=true. Read the warning in GitHub’s docs first. The option takes precedence over --allow-all-tools but not over --allow-all-paths or --allow-all-urls, and if it can’t be turned on, the CLI only writes a warning to standard error and keeps any --allow-all-tools you passed.
3. In the GitHub Copilot app, open the mode menu in the prompt box, click Tool permissions and select Assisted. That also becomes your default for new local sessions; change the default under Settings > Sessions.
4. In VS Code, select Assisted permissions in the permissions picker. VS Code’s docs, last updated October 21, add conditions: turn on the chat.assistedPermissions.enabled setting, and use Folder isolation, because “worktree sessions always use Allow all.” It isn’t offered for Local harness sessions, and the first time you pick it, a warning asks you to confirm.
5. For an organization, GitHub’s managed settings can block Allow all while leaving assisted available, with permissions.disableBypassPermissionsMode: "disable", turn assisted off with permissions.disableAssistedPermissionsMode: true, or set the starting mode with permissions.defaultMode. Developers can still pick any mode the policy allows.

How safe it is

GitHub is direct about it: “The model can make mistakes and approve dangerous or unintended actions. This feature is not a substitute for sandboxing or access restrictions.” VS Code’s security docs call it “not a security boundary.” GitHub hasn’t published how often its reviewer gets it wrong.

Anthropic has, for Claude Code’s equivalent, and its numbers show both sides. In a study with 1,053 paid testers, people caught 13.6% of dangerous commands slipped into their approval prompts, and auto mode caught 89%. But on real cases of Claude going further than the user had authorized, Anthropic’s engineering write-up measured a 17% miss rate, called it “the honest number,” and said that against careful manual review, auto mode is “arguably a regression.” Those are Anthropic’s figures for its own reviewer, not GitHub’s.

In practice:

• Choose assisted over Allow all. If you already run Copilot with --yolo, assisted adds a review where there was none, and in the CLI you can switch to it in the middle of a task.
• Keep manual for work with consequences, such as production credentials, deploys and anything that sends messages as you.
• Add a sandbox. GitHub offers local and cloud sandboxing for Copilot CLI, and VS Code’s terminal sandbox, once on, keeps restricting commands whatever the permission level.
• Mind where you start the agent. Last week, a planted AGENTS.md in a Downloads folder told Codex to install a malicious npm package, and in Forever Security’s tests it did in over 90% of attempts. Start agents only in folders you created.

How Claude Code, Codex and Cursor compare

Claude Code, Codex and Cursor each have their own version:

	GitHub Copilot	Claude Code	Codex	Cursor
Called	Assisted permissions	Auto mode	Approve for me, or Auto-review	Auto-review
Starts on by default	Not stated; the CLI may start in it	Yes, in the terminal and VS Code, from version 2.1.283	Not stated	Not stated
What it reviews	Commands, paths and URLs not already allowed, and in the CLI, admins’ ask rules	Actions before they run; your ask rules still prompt	Only actions that need approval, such as leaving the sandbox	Shell, MCP and Fetch calls not allowlisted or sandboxed
Who reviews	A model Copilot picks	A second model, the classifier	A separate Codex agent	Gemini 3.5 Flash Lite, with Haiku as the fallback
Counts toward usage	Not stated	Not on Pro, Max and Team	“Can add to Codex usage”	Not stated

The sources are Anthropic’s permission modes and auto mode article, OpenAI’s Auto-review and approvals docs, and Cursor’s Run Modes. Codex’s reviewer sees only requests to cross its sandbox: it “does not run for routine actions already allowed inside the sandbox,” and after 3 denials in a row it interrupts the turn. Claude Code’s docs say “explicit ask rules still force a prompt,” where Copilot CLI lets the model satisfy an administrator’s. Cursor calls Auto-review “the safest useful setup for most people,” and on Windows its new Computer Use goes through it too: after a user reported the agent clicking and typing in Chrome without asking, a Cursor staff member explained on October 24 that with Auto-review on, “anything it allows runs without a prompt.”

Claude’s apps on the web, desktop and mobile are due to start in auto mode this week on Pro, Max and Team, by Anthropic’s October 22 update. Our memo on that change has how to switch back.

What GitHub hasn’t said

• Which model reviews. Only that Copilot picks it and that it can differ from yours.
• How often it’s wrong. No miss rate or test results.
• What it costs. The docs don’t say whether reviews use your AI credits.
• Which plans have it. The announcement names products, not plans.
• Whether it will be the default. The CLI’s docs allow new sessions to start in either mode, without saying who gets which.

If you use more than one agent

Each lab’s reviewer has its own name, its own rules and its own switch, and the right setting differs by project. Enjoy doesn’t run Copilot or Cursor. It runs Claude Code, Codex, Grok Build and Muse Code on the plans you already have, each with its lab’s own modes, and in Enjoy each starts in its lab’s automatic mode, where a model decides what needs you: Claude Code’s Auto, Codex’s Approve for me, Grok Build’s Auto and Muse Code’s Auto-review. Enjoy remembers the mode you last used with each agent in each project, so a production repository can stay on manual approval while a side project runs with a reviewer. When an agent asks, the request appears as a card with the exact command, and Enjoy never picks a broader mode for you. Enjoy itself is free.

We’ll update this memo if GitHub publishes how its reviewer performs or makes assisted the default.