Bypass Permissions Safely: Every Coding Agent's Escape Hatch, and What Still Holds
Run agents? ACP lets you see, control, and price every tool call they make — allow/ask/deny policy, per-session cost, and a full audit log for Claude Code, Cursor, Codex, and OpenClaw, in one command:
curl -sf https://agenticcontrolplane.com/install.sh | bashGetting started → · see your first governed call → · free up to 5 agents · prefer fully on-device? add --local
Every coding agent ships a switch that stops it asking. The vendors don’t hide them — most are named after exactly how dangerous they are — but they’re spelled differently in every harness, they turn off different things, and only some of them leave anything standing.
This is the assembled table: nineteen agents in eighteen rows, their escape hatch, and what survives it. It’s the cross-harness companion to how to run Claude Code in yolo mode safely — same question, every agent.
The escape hatches, in one table
| Harness | The hatch | What it removes | What still holds |
|---|---|---|---|
| Claude Code (deep page) | --dangerously-skip-permissions (≡ bypassPermissions) |
Every permission prompt | Deny rules at all four scopes (managed denies can’t be overridden by any flag), explicit ask rules, MCP tools flagged as requiring interaction, PreToolUse hook blocks, an rm -rf / ⁄ rm -rf ~ circuit breaker that fires inside $(…); refuses to run as root |
| Codex CLI (deep page) | --yolo (approvals and sandbox); --sandbox danger-full-access (boundary only); --dangerously-bypass-hook-trust (one invocation’s hook review) |
Depends which — the tiering is the point | Wrapper unwrapping: sudo/env/trap peeled up to eight layers deep before a forced-delete verdict. Nothing records that a flag was set |
| Cursor / Cursor CLI (deep page) | Run Everything mode; CLI --force (alias --yolo) |
Sandbox, classifier, and prompts, all three | Mode-independent prompts for browser actions, file deletion, and writes outside the workspace. Cloud agents skip Run Modes entirely and auto-run inside a VM |
| Antigravity (Google) (deep page) | --dangerously-skip-permissions |
Everything, including the interception surface — verified live on 1.1.21 with an A/B pair of headless turns: with the flag, the PreToolUse hook layer is not invoked at all |
Nothing hook-based. This is the one row where a policy hook simply isn’t on the path |
| Muse Code (Meta) (deep page) | --yolo; also --disable-approval and --disable-sandbox separately |
--yolo: approvals + sandbox, and it trusts the workspace — loading the checkout’s AGENTS.md, rules and skills. --disable-sandbox alone also unconfines the file tools and forces full network egress |
Meta’s docs scope --yolo to disposable CI containers and warn that on a fork or PR checkout those workspace files are attacker-controlled |
| Grok Build (xAI) (deep page) | --always-approve / --yolo |
The prompts | Deny rules and PreToolUse hooks fire in every mode, always-approve included. Core hooks are fail-open on a 5s timeout |
| opencode (deep page) | --auto |
The ask tier only — the human, not the policy | Explicit deny rules remain enforced. The best-designed hatch of the major harnesses |
| DeepSeek Harness (dsh) (deep page) | No flag — the danger-full-access preset (approval never, sandbox open) |
Approvals and the sandbox | A named, visible profile decision rather than a flag someone leaves in a script. The review discipline is --dump-config |
| fx (Vercel Labs) (deep page) | yolo mode — /permissions yolo, permission_mode, or FX_PERMISSION_MODE |
Permission checks and the command sandbox; the run has the launching process’s full authority | A deliberate speed bump: yolo refuses to start until yolo_acknowledged is set. Nothing records that the controls were off |
| Hermes Agent (deep page) | yolo mode | The ~47-pattern inline prompt | Twelve hardline patterns, quoting-hardened, hold in every mode (our read) |
| Crush (Charm) | --yolo |
The permission service | Still hard-blocks ssh, scp, rsync |
| Aider | --yes-always |
Confirmation on edits | Shell execution is auto-denied, not auto-approved. The one command it won’t run unattended is the one that could hurt you — the most elegant inversion in the set |
| Goose (Block / LF) | GOOSE_MODE=auto — which is the default |
Everything | ~35 danger patterns ship, but off by default, and prompt-only even when on. Maintainers filed their own issue about the default and kept it |
| OpenHands | --always-approve / --yolo |
Confirmation mode | Their docs say it plainly: no hard-deny at the analyzer boundary. Headless mode is always-approve with no way to change it. The sandboxed runtime is the remaining bound |
| Amp (Sourcegraph) | amp.dangerouslyAllowAll |
— the default is already no approval prompts | amp.permissions rules and guardedFiles.allowlist, until the flag |
| Cline (guide) | None needed — CLI default is auto-approve ON; yolo is a literal "*": autoApprove |
Every tool, no exceptions, no protected paths | Nothing. The “safe commands” tier trusts the governed model’s own requires_approval self-classification |
| pi / Prime Agent (pi, Prime Agent) | None needed — the default is full access, by design and documented | n/a | Nothing built in. Both point you at containment instead: micro-VM, Docker, OpenShell |
| OpenClaw (deep page) | None needed — default is exec security: "full" with ask: "off" |
n/a | The most-starred agent’s default configuration is what every other harness calls its escape hatch. Its docs are candid that this is single-operator UX, not isolation |
Two rows worth reading twice. Gemini CLI — retired in June 2026 and folded into Antigravity — blocked command substitution even in yolo, the cleanest “no mode bypasses this” design anyone shipped, and its successor’s flag is the most total in the table. And Aider, which is the only harness that understood the assignment in the other direction: full-auto should make the dangerous thing unavailable, not automatic.
The three shapes
Line the rows up and every hatch is one of three things.
1. The flag that removes the prompts. Claude Code, Grok Build, opencode. The permission prompts stop; the rule engine and the hook layer keep running. This is the good shape, and the reason is worth naming: the prompt is a request a tired human waves through, and the rule is a boundary that runs whether they wave or not. In all three, what you wrote in advance is exactly what you still have.
2. The flag that removes the interception surface. Antigravity is the pure
case — verified, the hook layer isn’t invoked at all. Cursor’s Run Everything
takes out sandbox, classifier and prompts together. Muse Code’s --yolo goes
further than most people read: it also trusts the workspace, loading the
checkout’s own instruction files, which on a fork or PR checkout are
attacker-controlled input. In this shape, a control layer isn’t weakened — it’s
absent, and nothing in the session says so.
3. The default that already is the escape hatch. OpenClaw, pi, Prime Agent, Cline’s CLI, Goose, Amp. There’s no flag to audit because there’s no gate to open. The honest ones say so — pi’s docs state there is no permission system and point at containment; OpenClaw’s describe their default as operator-intent guardrails rather than isolation. Read the default, not the flag list.
What none of them do
Here’s the finding that survives every row: no harness in this table records
that its escape hatch was used. The flag disables the controls and the record
of the controls being disabled, in one action. Codex’s page says it directly —
an unattended invocation is one --yolo in a cron job away from no controls at
all, and nothing writes that down. fx’s yolo leaves no trace the checks were
off. Antigravity produces no hook execution, no decision, no record.
That’s not a per-vendor oversight, it’s the structural gap in every native control model: the record is written by the process it describes, on the machine that ran it, and is editable by whoever flipped the flag. A log that goes quiet is indistinguishable from a session that did nothing.
It gets multiplied by fleets. Orca’s launch layer
keeps a per-harness map of skip-approval flags — --dangerously-skip-permissions
for Claude Code, --dangerously-bypass-approvals-and-sandbox for Codex, --yolo
for Gemini, Copilot and Cursor, --auto-approve true for Cline, --yes-always
for Aider, across ~30 agents — and that map is its default launch
configuration. It’s user-visible, with a Manual toggle, and it is still the case
that the product which makes it easiest to run ten agents defaults all ten to
this table’s right-hand column.
Why the bypasses keep coming back
Every few months a new write-up demonstrates a way around some harness’s allowlist, and the shape is always the same. Cursor retired its command denylist after a security firm showed four routes around it — Base64 encoding, subshells, and writing the blocked command to a script and then running the script — and has since published three separate allowlist-bypass CVEs (command substitution, environment-variable poisoning and shell built-ins, and web content injected into auto-execution). Their docs are now unusually blunt about there being no security boundary between the agent and your user account.
That isn’t a Cursor problem, and the CVE numbers aren’t the lesson — the class is. A permission rule matches a command string; the effects of a shell command are not recoverable from its prefix. Any prefix-matched deny list on a Turing-complete tool is a speed bump, which is why Anthropic’s own docs call argument-constrained Bash patterns fragile and recommend a hook or a sandbox for anything that must hold. We walk the mechanics in Claude Code’s deny list can be bypassed; the survey that first convinced us it was universal is what survives yolo mode.
Expect the next cycle. When it lands, the useful question is not “is my harness on the list” but the two below.
The two questions to ask any escape hatch
Which of my controls survive the flag? Of the eight harness control
patterns, exactly two survive an escape hatch by
construction — a proxy the calls must transit, and an off-machine record. Pattern
rules survive sometimes (Claude Code’s denies, opencode’s denies, Grok Build’s).
Hooks survive in some harnesses and not others, and “reads your hook config” is
not the same as “honours your hook’s verdict” — Grok Build loads hooks straight
out of ~/.claude/settings.json and parses only its own decision vocabulary, so
the hook runs, the log looks healthy, and nothing is ever blocked.
Does anything record that it was used? On current harnesses, the answer is no. Which means the control worth having is one whose record isn’t written by the process that flipped the flag — what our layer intercepts per harness is the version of that we maintain, and the same question asked of every native model is the controls comparison.
Honest limits
This table is a snapshot, and this class of page ages fast. Cursor alone went
yolo mode → Auto-Run → Run Modes and deleted two modes in a single month; Codex
removed --full-auto in 0.147; Gemini CLI’s policy engine no longer exists.
Every row here is from primary sources read for the controls
comparison and its per-harness deep pages, and we correct these pages
when the harnesses move. Check the deep page’s date before you rely on a row.
“What still holds” is not “what is safe.” Claude Code’s circuit breaker
catches rm -rf /; it does not catch the same deletion written as a Python
one-liner. Crush blocking ssh does not bound curl. A surviving floor is a
floor, and the useful reading of a good right-hand column is this harness will
stop the catastrophe it has already seen, not this harness is contained.
A sandbox and a policy answer different questions. The rows with the best containment stories (OpenHands’ runtime, Cursor’s cloud VM, pi’s suggested micro-VM) bound the blast radius without deciding anything per action; a destructive command against a database you legitimately have credentials for is inside the sandbox and runs. Most real setups want both — the box for radius, the per-call check for the in-bounds-but-wrong actions. Sandboxes and control planes is the longer treatment.
We are in our own table’s blast radius. A hook-based layer is a pattern-5 control: it survives Claude Code’s and Grok Build’s escape hatches, and it is simply not on the path under Antigravity’s. We say that on the Antigravity page too. The only patterns that don’t have this property are the ones that don’t live inside the thing the flag disables.
Rows compiled from each harness’s official documentation and source, via the per-harness deep pages linked in the table; current to August 2026. Corrections welcome — this page is meant to be the durable home for the question, so it gets updated rather than replaced when the next bypass cycle lands.
What is the bypass permissions flag for each coding agent?
Claude Code and Antigravity use –dangerously-skip-permissions; Codex CLI, Cursor’s CLI, Muse Code, Grok Build, Crush and OpenHands use –yolo (Cursor’s canonical spelling is –force); Aider uses –yes-always; opencode uses –auto; Codex also has –sandbox danger-full-access, and DeepSeek Harness ships danger-full-access as a named preset rather than a flag; Amp uses amp.dangerouslyAllowAll; fx has a yolo mode gated behind a yolo_acknowledged setting. Several agents need no flag at all because permissive is already the default: pi, Prime Agent, OpenClaw, Cline’s CLI, and Goose (whose default mode is auto).
Which coding agents keep enforcing something in yolo mode?
A minority, and the survivors differ. Claude Code keeps deny rules at every scope, PreToolUse hooks, and an rm -rf circuit breaker. Grok Build keeps deny rules and PreToolUse hooks. opencode keeps explicit deny rules and drops only the ask tier. Hermes keeps twelve quoting-hardened hardline patterns. Crush still hard-blocks ssh, scp and rsync. Aider inverts it and auto-denies shell execution rather than auto-approving it. Antigravity is the clearest counterexample: its flag removes the hook layer from the call path entirely.
Is it safe to use a coding agent's yolo mode?
It depends entirely on whether anything in that harness survives the flag, and on whether you wrote those rules in advance. Ask two questions of any agent before you use its escape hatch: which of my controls still run with the flag on, and does anything record that the flag was set? On current harnesses the second answer is almost universally no — the flag disables the controls and the record of the controls being disabled at the same time.
Why do coding agents keep having permission bypass vulnerabilities?
Because most permission systems match command strings, and a string has many spellings. Cursor retired its command denylist after a security firm demonstrated four ways around it — Base64 encoding, subshells, and writing the blocked command to a script then running the script — and has since published three allowlist-bypass CVEs. The class recurs across harnesses because it is structural, not a coding error: the effects of a shell command are not recoverable from its prefix.