BuildNot yet confirmed elsewhere1 publisher2 min readPublished
Copilot's --yolo removes the approval prompt but still obeys --deny-tool rules
Copilot's --yolo, /yolo and VS Code's Allow all remove only the approval prompt, according to a dev.to walkthrough of the Copilot docs. Deny rules still win, and the CLI and VS Code use separate permission systems that each need configuring.
The Engineer · Build desk
CLI users: --yolo equals --allow-all, all tools, paths and URLs. VS Code users: Allow all via picker, /yolo or settings.json. CLI and VS Code configs are separate. CI: COPILOT_ALLOW_ALL=true acts as --yolo, trusts the directory. Deny rules win over --yolo. Admins can turn it all off.
- capability Copilot CLI users --yolo is the same flag as --allow-all: all tools, all paths and all URLs at once, claim 1
- capability VS Code users Allow all via the chat permission picker, /yolo, or chat.tools.global.autoApprove in settings.json, claim 2
- constraint CLI and VS Code configs Separate permission systems; nothing set in VS Code changes the CLI, and vice versa, claim 4
- capability CI runs COPILOT_ALLOW_ALL=true acts as --yolo and trusts the current directory; called the CI-friendly form, claim 7
- constraint Anyone running --yolo A deny rule always wins, as in --yolo --deny-tool 'shell(git push)', claim 6
- decision Admins disableBypassPermissionsMode: disable turns off all of this; allow-auto-only limits users to assisted mode, claim 12
| Who | How | Kind | Claim |
|---|---|---|---|
| Copilot CLI users | --yolo is the same flag as --allow-all: all tools, all paths and all URLs at once | capability | 1 |
| VS Code users | Allow all via the chat permission picker, /yolo, or chat.tools.global.autoApprove in settings.json | capability | 2 |
| CLI and VS Code configs | Separate permission systems; nothing set in VS Code changes the CLI, and vice versa | constraint | 4 |
| CI runs | COPILOT_ALLOW_ALL=true acts as --yolo and trusts the current directory; called the CI-friendly form | capability | 7 |
| Anyone running --yolo | A deny rule always wins, as in --yolo --deny-tool 'shell(git push)' | constraint | 6 |
| Admins | disableBypassPermissionsMode: disable turns off all of this; allow-auto-only limits users to assisted mode | decision | 12 |
What happened
- In the CLI, --yolo is the same flag as --allow-all, shorthand for allowing all tools, all paths and all URLs at once.
- VS Code has three routes to Allow all: the chat permission picker, a /yolo command, and a permanent chat.tools.global.autoApprove setting in settings.json.
- The environment variable COPILOT_ALLOW_ALL=true does what --yolo does and also trusts the current directory, which the walkthrough calls the CI-friendly form.
- Admins can set disableBypassPermissionsMode to disable under permissions to shut all of it off, or allow-auto-only to limit users to the assisted mode.
Why it matters
- constraint The sandbox exemption is documented for VS Code. The walkthrough's CLI section names deny rules as the control that outlasts YOLO, so for CLI runs the deny list is the one confirmed backstop.
- cost A team that uses both runtimes maintains two permission configs. A setting made in VS Code does nothing for a copilot process launched from CI.
- decision Each unattended run needs a posture chosen on purpose: --allow-all-tools alone or full --yolo, since the walkthrough treats them as materially different, and usually Autopilot on top.
- exposure Under YOLO, any call that no deny rule matches runs with no human in the loop. In our view the deny list becomes the working policy, so what it omits is what the agent can do.
The walkthrough's author checked it on October 7, 2026 against GitHub's Copilot CLI reference, the 1.0.93 changelog and the VS Code agent docs [18]. It lays the path from model to machine out as three gates in order: deny rules, the approval prompt, and the sandbox if one is enabled [5]. YOLO removes the second. Two of the three stay in place [17].
Deny rules are the part a team can write today. In the CLI, `--allow-tool` and `--deny-tool` take typed patterns such as `shell(git:*)`, `write(src/*.ts)`, `read(.env)` and `url(github.com)` [16]. A deny always wins, including over `--yolo`, and the author calls `--yolo --deny-tool 'shell(git push)'` a cheap "YOLO minus the footguns" profile [6].
The two runtimes share a command name and little else. Copilot ships a terminal agent with flag-driven permissions and an editor agent whose permissions hang off a picker and `settings.json` [4]. Typing `/yolo` in each reaches a different permission system [4]. To undo it in VS Code chat, the commands are `/disableYolo` or `/disableAutoApprove` [14]. In the CLI, `/permissions` is now the canonical command, with four arguments: `default`, `assisted`, `allow-all` and `show` [15].
Unattended runs need a second switch. Autopilot keeps the agent iterating, and YOLO approves its tool calls [9]. Autopilot without YOLO works until the first approval and then blocks. YOLO without Autopilot approves calls, but the agent stops to check in [9]. Shift+Tab in the CLI does not toggle YOLO. It cycles standard, plan and autopilot [10].
VS Code's security docs, as the walkthrough quotes them, say Autopilot "combines auto-approval with autonomous iteration" and "reduces your ability to review intermediate steps" [13].
Assisted permissions are a middle option. `/permissions assisted` puts a safety model in front of the prompt, approving routine requests and escalating the rest [11]. It is a classifier in the approval layer. It reduces prompts and adds no isolation [11].
What to watch
- Copilot CLI changelog entries after 1.0.93, the release the walkthrough was checked against, for any change to what --yolo or --allow-all covers.
- GitHub's CLI reference on whether an enabled sandbox is honored under --yolo, which the walkthrough documents only for VS Code.
- Whether the admin setting disableBypassPermissionsMode shows up in team policy templates for unattended Copilot agents.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence58
- Adoption
- Insufficient
- Hype gap−5
- Incentives
- Insufficient
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
In the Copilot CLI, --yolo is the same flag as --allow-all, and /yolo does the same in a running session; it is shorthand for --allow-all-tools plus --allow-all-paths plus --allow-all-urls.
- [2]
In VS Code, Allow all is reached through the chat permission picker, by typing /yolo, or by setting "chat.tools.global.autoApprove": true in settings.json to make it permanent.
- [3]
YOLO skips approval prompts. It does not skip --deny-tool rules, and in VS Code it does not skip an enabled sandbox, which the VS Code docs document explicitly.
- [4]
Copilot ships two agent runtimes with two permission systems: the CLI is a terminal agent with flag-driven permissions, and Copilot Chat in VS Code is an editor agent whose permissions hang off a picker and settings.json. They share vocabulary, including /yolo, but not config; nothing set in VS Code changes the CLI, and vice versa.
- [5]
There are three gates between the model and the machine: deny rules, which always win; the approval prompt, which is the only layer YOLO removes; and the sandbox, if enabled, which still limits files and network.
- [6]
A deny rule always wins, including over --yolo, which gives a cheap "YOLO minus the footguns" profile: --yolo --deny-tool 'shell(git push)'.
- [7]
The environment variable COPILOT_ALLOW_ALL=true does the same as --yolo and also trusts the current directory, which the walkthrough calls the CI-friendly form.
- [8]
Tools, paths and URLs are separate trust dimensions. For a threat model where the agent may run npm test but must not read ~/.ssh or send data to arbitrary hosts, --allow-all-tools alone is a materially different posture from --yolo.
- [9]
Autopilot keeps the agent iterating; YOLO approves its tool calls. Autopilot without YOLO keeps working and then blocks on the first approval; YOLO without Autopilot approves calls but the agent stops to check in. An unattended run usually needs both.
- [10]
Shift+Tab does not toggle YOLO in the Copilot CLI; it cycles standard, plan, autopilot, which is a mode-of-work switch and not a permission switch.
- [11]
/permissions assisted puts a safety model in front of the prompt, approves routine requests and escalates the rest; it is a classifier in the approval layer, not a sandbox, so it reduces prompts without adding isolation.
- [12]
Admins can set "disableBypassPermissionsMode": "disable" under permissions to turn off all of this, and "allow-auto-only" restricts users to the assisted mode.
- [13]
VS Code's security docs say Autopilot "combines auto-approval with autonomous iteration" and "reduces your ability to review intermediate steps".
ReportedSupportedSource: VS Code security docs, as quoted in the dev.to walkthroughView cited source - [14]
In VS Code chat, /yolo or /autoApprove applies for the current session, and /disableYolo or /disableAutoApprove undoes it.
- [15]
In the Copilot CLI, /permissions is now the canonical command, with four arguments: default, assisted, allow-all and show.
- [16]
--allow-tool and --deny-tool take typed patterns such as shell(git:*), write(src/*.ts), read(.env), url(github.com) and MyMCP(create_issue).
- [17]
Two of the three gates remain in place when YOLO is on.
- [18]
The walkthrough says everything in it 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.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toCopilot YOLO mode, dissected: what --yolo, /yolo and Allow all actually skip
1 article · October 12, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Developer ToolingFollow
- AI coding agent permissionsFollow