Copilot YOLO mode, dissected: what --yolo, /yolo and Allow all actually skip

TL;DR

• Copilot CLI: copilot --yolo (same flag as --allow-all), or /yolo in a running session. It is shorthand for --allow-all-tools + --allow-all-paths + --allow-all-urls.
• VS Code: pick Allow all in the chat permission picker, type /yolo, or set "chat.tools.global.autoApprove": true to make it permanent.
• What it skips: approval prompts. What it doesn't: your --deny-tool rules, and (in VS Code, explicitly documented) an enabled sandbox.
• Autopilot is a different switch. It keeps the agent iterating; YOLO approves its tool calls. Unattended runs usually want both.

Everything here was checked on October 7, 2026 against GitHub's Copilot CLI reference, the github/copilot-cli changelog (1.0.93) and VS Code's agent docs in microsoft/vscode-docs.

Why does "YOLO" mean two different things in Copilot?

Because Copilot ships two agent runtimes with two permission systems. The Copilot CLI is a terminal agent with flag-driven permissions. Copilot Chat in VS Code is an editor agent whose permissions hang off a picker and settings.json. They share vocabulary (/yolo exists in both) but not config. Nothing you set in VS Code changes the CLI, and vice versa.

The one thing they agree on is the layering. There are three separate gates between the model and your machine:

model wants to act
   │
   ▼
[1] deny rules ─────────── always win, YOLO or not
   │
   ▼
[2] approval prompt ────── this is the only layer YOLO removes
   │
   ▼
[3] sandbox (if enabled) ─ still limits files + network
   │
   ▼
your shell / filesystem / network

Keep that picture in mind; every flag below is about layer 2.

What exactly does copilot --yolo turn on?

copilot --yolo

--yolo and --allow-all are the same flag, documented as "Enable all permissions (tools, paths, and URLs)". It decomposes into three narrower switches you can use on their own:

Flag	What stops asking
--allow-all-tools	every tool call (GitHub notes this is required when you drive the CLI from a script)
--allow-all-paths	the check on which file paths the agent may touch
--allow-all-urls	URL fetch approval

The env var COPILOT_ALLOW_ALL=true does the same as --yolo and trusts the current directory, which makes it the CI-friendly form: no flag plumbing through wrapper scripts.

The nerdy bit worth noticing: paths and URLs are separate trust dimensions from tools. If your threat model is "the agent may run npm test but must not read ~/.ssh or exfiltrate to random hosts", --allow-all-tools alone is a materially different posture from --yolo.

How do the in-session commands map onto each other?

/permissions is now the canonical command, with four arguments: default, assisted, allow-all and show. Everything else is an alias:

• /yolo and /allow-all → /permissions allow-all
• /yolo also takes off, auto and show
• /reset-allowed-tools (or /permissions default) undoes it

While it's on, the footer shows a YOLO indicator, so you can't forget you're flying without a net.

One gotcha for people coming from other agents: Shift+Tab does not toggle YOLO in the Copilot CLI. It cycles standard → plan → autopilot. That's a mode-of-work switch, not a permission switch.

Why isn't Autopilot the same thing as YOLO?

Two orthogonal axes:

• Autopilot (--autopilot, /autopilot, or Shift+Tab) answers "should the agent keep going without checking in with me?"
• YOLO answers "should the agent run tools without asking me?"

Autopilot without YOLO: the agent keeps working, then blocks on the first approval. YOLO without Autopilot: approvals fly through, but the agent stops to check in. An unattended run usually needs both. VS Code's security docs make the same point from the other side: Autopilot "combines auto-approval with autonomous iteration" and "reduces your ability to review intermediate steps".

Can I get most of the speed without approving everything?

Yes, and this is where Copilot's design is genuinely nice. Two halfway layers:

Pattern rules. --allow-tool and --deny-tool take typed patterns:

copilot --allow-tool 'shell(git:*)' --deny-tool 'shell(git push)'

Other shapes: write(src/*.ts), read(.env), url(github.com), MyMCP(create_issue). The rule that matters: a deny always wins, including over --yolo. That gives you a cheap "YOLO minus the footguns" profile: --yolo --deny-tool 'shell(git push)'.

Assisted permissions. /permissions assisted puts a safety model in front of the prompt. It approves routine requests and only escalates the rest to you. It's a classifier in layer 2, not a sandbox, so it reduces prompts without adding isolation.

Admins get the last word: "disableBypassPermissionsMode": "disable" under permissions kills all of this, and "allow-auto-only" restricts users to the assisted mode.

How does VS Code's version work?

Copilot Chat calls it Allow all, one of three permission levels:

Level	Behavior
Manual (default)	asks for each tool call
Assisted	a model approves routine requests (needs chat.assistedPermissions.enabled)
Allow all	asks for nothing; VS Code warns you the first time

Three ways in:

1. The permission picker in the chat input.
2. /yolo or /autoApprove in chat, for the current session. Undo with /disableYolo or /disableAutoApprove.
3. Permanently, in settings.json:

{ "chat.tools.global.autoApprove": true }

That last one approves every tool in every workspace, and VS Code's own docs flag it as a setting that "disables critical security protections". The docs recommend the session-scoped Allow all when you don't need auto-approval everywhere. The experimental chat.permissions.default (default, autoApprove, autopilot) picks the level new chats start with, and orgs can block global auto-approve with the ChatToolsAutoApprove policy.

Are terminal allowlists enough to keep me safe?

They're the VS Code halfway option:

{
  "chat.tools.terminal.autoApprove": {
    "mkdir": true,
    "/^git (status|diff|log)\\b/": true,
    "rm": false
  }
}

Keys are prefixes or regexes. true auto-approves; false forces a prompt even if another rule would approve. Note that false means ask, not block.

But read the fine print: VS Code's security docs say auto-approval rules "use best-effort command parsing and have known limitations with shell aliases, quote concatenation, and complex shell syntax". Anyone who has written a shell parser knows why: g'it' push, an alias, or bash -c "$(…)" can all slip past a prefix match. Treat allowlists as a convenience, and put the real boundary somewhere that enforces it at the OS level.

What does the sandbox actually enforce, and what doesn't YOLO touch?

In VS Code, turn on chat.agent.sandbox.enabled (or the Sandboxing for terminal toggle in the picker). The docs are explicit that Allow all and Autopilot skip prompts "but an enabled sandbox still restricts terminal file system and network access". Under the hood VS Code's docs list:

• macOS: Apple's Seatbelt, built in.
• Linux / WSL2: bubblewrap for filesystem isolation plus socat for network proxying (apt-get install bubblewrap socat). WSL1 is out, because bubblewrap needs user namespaces.

Two caveats from the same docs: outbound network stays on by default (chat.agent.sandbox.network.allowNetwork defaults to true), so lock that down separately; and the sandbox is "not a virtual machine or user-account boundary". If you see the older key chat.tools.terminal.sandbox.enabled in blog posts, it's no longer in VS Code's docs.

The Copilot CLI has /sandbox / --sandbox too. GitHub's reference still marks it experimental while the changelog says it's available to everyone, and the CLI docs don't say whether --yolo bypasses it. We treat it as a separate layer like VS Code's, but if you rely on it, check what /sandbox reports.

Can a cloned repo flip YOLO on for me?

In VS Code, the front-line defense is Workspace Trust: an untrusted folder opens in restricted mode, which "also disables agents". So review a repo before you trust it, because trust is what unlocks agents in it at all. The global auto-approve setting is something you set yourself, and the docs steer you to the session-scoped level instead. The CLI has a notion of trusted directories too: COPILOT_ALLOW_ALL=true trusts the current directory, and /add-dir PATH grants file access to another directory and loads its .github/skills and .github/agents as trusted configuration. That's worth remembering before you point a YOLO session at a repo you haven't read.

How do I turn on YOLO per task or per workspace with AgentRQ?

Copilot's YOLO is session-scoped: once on, it's on for everything that session does. If you'd rather decide per task, and answer prompts from somewhere other than the terminal, you can route the Copilot CLI through AgentRQ via the ACP Gateway (Copilot setup guide):

npx @agentrq/acp-gateway@latest --agent github-copilot-cli

This covers the Copilot CLI only; Copilot Chat in VS Code keeps its own picker.

Start Copilot without --yolo. The gateway moves each new session out of any mode that would approve on its own and into one where Copilot asks a person. Every permission request then lands in the AgentRQ task (web, phone or Slack) with the command or edit attached, and you answer:

• Allow Once: this call only.
• Always Allow: adds the tool to the workspace's auto-approved list, so routine calls stop asking.
• Deny: Copilot gets a refusal and carries on.

If nobody answers within 30 minutes, the gateway cancels the turn rather than guessing; tune that with --permission-timeout.

Per task. Flip the YOLO toggle on a task, or set it when you create one, to put just that task in YOLO mode. Every permission request in it is auto-approved and Copilot never waits, while every other task in the workspace still asks. The setting sticks to the task even if the agent disconnects and reconnects. Scheduled tasks, event triggers and workflow steps have the same switch, so the nightly job can run in YOLO while your interactive work stays supervised.

Per workspace. Workspace settings has YOLO Mode (Execute All) (UI warning: "Agent will not ask for permission"). Under the hood it's a default, not a global override: the approval check reads the task's own YOLO flag, and the workspace switch decides what that flag starts as. New tasks you create in the web form open with the YOLO toggle already on (you can still switch it off per task), and tasks the agent creates for itself over the workspace MCP server inherit it. Flipping the switch doesn't rewrite tasks that already exist.

Or let a model approve and deny for you, from plain-English rules. Between "ask me every time" and "approve everything" there's a third option: an AgentRQ desktop extension that reviews each permission request before it reaches you. Extensions are trusted Node modules loaded by the AgentRQ desktop app. One registers a reviewer with ctx.hooks.add({ id, review(request) { ... } }) and is handed the pending call: the tool name, the argument preview the harness sent, and the workspace. It answers { behavior: 'deny', reason }, { behavior: 'allow' }, or nothing at all to abstain. Point review() at an external decision API such as TypeSafe's Jev, a "System One" model that returns a typed choice with calibrated probabilities and a confidence in milliseconds instead of generating text. Send the tool call as the state, and your workspace's rules in plain English ("git push is fine on feature branches, never on main", "never read anything under ~/.aws") as a Choice question over allow / deny / ask me. Then threshold it: approve only on a high-confidence allow, refuse on a confident deny, and abstain on everything else so the request lands on your phone as usual. The rules can live on a per-workspace settings tab the extension draws itself; the bundled guardrail example does exactly that with literal patterns.

The review contract is built on one asymmetry: refusing costs a tool call, approving costs whatever the tool call does. So one refusal settles a request; silence (an abstain, an exception, or a reviewer that misses its 5-second deadline) is never an allow, the request just stays in front of you; and an extension needs the decide consent level to approve, while deny consent can only refuse. The install screen starts every extension at none. Reviews only happen while the desktop app is open and signed in, so treat this as a fast first pass, not a security boundary.

The trade-off. Workspace-wide is one click and zero prompts, but it outlives the job you actually trusted: the next task inherits it whether you meant to or not. Per-task YOLO expires with the task. Our default is the workspace switch off, per-task YOLO for the jobs you've vetted, Always Allow for the boring tools, the sandbox on, and a clean git tree before every YOLO run. The tool call history keeps a record of every call, including the auto-approved ones.

FAQ

Is copilot --yolo the same as --allow-all? Yes. Same flag: tools, paths and URLs.

Does --yolo override --deny-tool? No. A deny always wins.

Why doesn't Shift+Tab turn on YOLO in the CLI? It cycles standard, plan and autopilot. Use /yolo.

How do I make Allow all permanent in VS Code? "chat.tools.global.autoApprove": true, though the session-scoped picker level is the safer habit.

Does Allow all disable the VS Code sandbox? No. An enabled sandbox still restricts terminal filesystem and network access.

Is Autopilot YOLO? No. Autopilot keeps the agent going; YOLO approves its tool calls.

For every other agent, see what YOLO mode is and how to turn it on in every coding agent.

Your turn: do you run Copilot with --yolo plus a couple of --deny-tool guards, or do you trust the assisted classifier more than your own regexes? Tell me your setup in the comments.

---

Originally published on AgentRQ.