The fortieth y is where it happens. Your coding agent has been grinding through a refactor for twenty minutes, and every shell command, file write, and network call stops to ask permission. You approve, approve, approve — until the flag in the docs starts to look reasonable: --dangerously-skip-permissions. The documentation is blunt about what you get in return. That mode "offers no protection against prompt injection or unintended actions." You have traded every guardrail for silence.
That trade is a false binary. The choice was never "confirm everything" versus "confirm nothing" — those are the two endpoints of a spectrum that now has real gradations in the middle. Understanding the mechanism behind that middle tells you exactly when to trust it and when a prompt is still the right answer.
Six modes, not two
Claude Code exposes permission behavior as a mode you cycle through, and the current lineup makes the spectrum concrete:
| Mode |
What runs without asking |
default (Manual) |
Reads only |
acceptEdits |
Reads, file edits, common filesystem commands |
plan |
Reads only, no edits |
auto |
Everything, with background safety checks |
dontAsk |
Only pre-approved tools |
bypassPermissions |
Everything, no checks |
bypassPermissions and default are the endpoints everyone reaches for first. The one worth understanding is auto — the only mode that replaces the human prompt with something other than nothing.
A second model, watching the first
In auto mode, a separate classifier model reviews each action before it runs — an independent check with its own inputs and verdict, not the working model grading its own homework. The threat model it defends against has four named categories: an overeager agent taking unauthorized initiative (hunting for credentials, deleting an obstacle), an honest mistake about resource scope, a hijack by prompt injection planted in a file or tool output, and — not yet observed in practice — a genuinely misaligned model pursuing its own goals.
The decision order is fixed, and the first matching step wins:
- Your explicit allow, ask, and deny rules resolve immediately.
- Read-only actions and file edits inside your working directory are auto-approved.
- Everything else — shell commands, network calls, external tools — goes to the classifier.
The classifier runs as a two-stage pipeline. Stage one is a fast single-token yes/no filter tuned to be trigger-happy, flagging roughly 8.5% of actions as suspicious. Only those reach stage two, a slower chain-of-thought pass that reconsiders with full reasoning and drops the false-positive rate to about 0.4%. Cheap and aggressive up front, expensive and careful only where it matters.
What it deliberately cannot see
The most important design decision is what the classifier is not shown. It sees your messages, the agent's tool calls, and your CLAUDE.md — and nothing else. Claude's own explanatory text is stripped out, so the agent cannot talk the classifier into a bad call with a persuasive rationalization. Tool results are stripped too, so hostile text sitting in a file or a fetched web page never reaches the classifier directly. A separate server-side probe scans incoming tool outputs for injection attempts and flags them before the agent reads them.
There is a second consequence of this design that bites in practice. State a boundary in plain language — "don't push to production," "wait for my review before deploying" — and the classifier treats it as a block signal. But boundaries are not stored as rules. The classifier re-reads them from the transcript on every check, so context compaction can quietly evict the message that stated one. For anything you actually need to hold, encode it as a rule, not a sentence:
{
"permissions": {
"defaultMode": "auto",
"deny": ["Bash(terraform apply:*)", "Bash(git push:*production*)"]
}
}
Deny rules apply in every mode, including auto and bypassPermissions, and survive compaction because they were never in the transcript to begin with. (One gotcha: defaultMode: "auto" is honored only from user settings at ~/.claude/settings.json — a repository cannot vote itself into auto mode through checked-in project settings.)
The honest numbers
None of this is presented as a safety guarantee, and the honesty about the gap is what makes it usable. On a set of 52 genuinely overeager actions, the full pipeline still missed 17% — cases where some consent signal existed in the conversation but did not clearly cover the action's blast radius. The framing in the engineering write-up is worth sitting with:
A substantial improvement over unrestricted execution, but arguably a regression versus careful manual review.
That is the correct mental model: auto mode is strictly better than skipping permissions and strictly worse than a human actually reading each diff. It buys back most of the safety of manual review while keeping most of the throughput of bypass. And when a run stalls — three blocked actions in a row, or twenty across the session — it stops guessing and hands control back with a prompt.
Classification is judgment; a sandbox is enforcement
Here is the distinction that reorganizes the whole picture: auto mode does no capability isolation. It reads a command string and forms a judgment about whether running it is safe. If an allowed command turns out to do more than its name suggests, the classifier has already waved it through.
The sandbox is the other half, and it works on a different principle. It uses OS-level primitives — Seatbelt on macOS, bubblewrap on Linux and WSL2 — to confine what a Bash process and its children can touch on the filesystem and network. That boundary holds regardless of what the model chose to run, and even if a command misbehaves once running. Classification happens before execution and reasons about intent; the sandbox happens during execution and enforces on the process.
They are complementary layers, and the right answer for unattended work is to stack them:
- Sandbox for hard, OS-enforced blast-radius limits that no model choice can override.
- Auto mode for intent-level judgment on the actions that reach outside the sandbox.
- Deny rules for the handful of specific things that must never happen, no matter the mode.
bypassPermissions sits outside all three. It is not a stronger version of autonomy — it is the removal of the layers that make autonomy defensible, kept around for the one legitimate case: a genuinely disposable, network-isolated container where there is nothing to protect.
So when the fortieth y tempts you toward the dangerous flag, the move is not to disable oversight — it is to change the kind. Turn on the sandbox so the filesystem and network are bounded by the OS. Switch to auto mode so a second model vets what leaves those bounds. Pin the two or three actions you never want as deny rules so they outlive your context window. That is autonomy you can leave running, because when it is wrong, it is wrong inside walls you built on purpose.
Sources: Choose a permission mode — Claude Code Docs, Configure the sandboxed Bash tool — Claude Code Docs, How we built Claude Code auto mode: a safer way to skip permissions — Anthropic