You're ten approval prompts into a deploy. Edit a file, approve. Run the migration, approve. Somewhere around the fourth one you stop reading them and just hit yes, which is exactly the moment the prompts stopped protecting you.
So you do what half the people in your team chat did: alias claude --dangerously-skip-permissions and call the problem solved. No more prompts. Job done.
Except you've now turned off the thing that catches a prompt-injected agent from emailing your .env to a server in another country. And the alternative everyone keeps mentioning, "auto mode," you've never actually looked at, because the only explanations out there are a vague Google AI Overview and a stack of Reddit threads that contradict each other.
Here's the clean version. The thing that matters is what kind of safety each mode uses, not how permissive it is.
What Claude Code auto mode actually is
Auto mode auto-approves every action and runs each one through a separate classifier model that blocks anything dangerous before it executes. You start it with claude --permission-mode auto, and it needs Claude Code v2.1.83 or later.
The common assumption, the one the AI Overview will hand you, is that auto mode approves "safe operations" and prompts on the rest. That's wrong. It approves everything: edits, shell, network, the lot. There's no safe-versus-unsafe sorting happening at the prompt layer.
The safety lives one layer down, in the classifier. It blocks anything that escalates beyond what you asked for, targets infrastructure it doesn't recognise, or looks like it's being driven by hostile content the agent just read in a file or web page. The model is "no prompts, with an ML model watching the actual actions and stepping in when one looks wrong," not "fewer prompts on safe stuff."
It still respects your deny rules. Explicit ask rules still force a prompt. And it has a fallback: block an action three times in a row, or twenty times total in a session, and auto mode gives up and starts prompting you again.
One more useful detail for the working engineer. The classifier treats things you say in conversation as instructions. Tell Claude "don't push until I've reviewed" and it blocks pushes, even ones the default rules would allow, until you lift the boundary in a later message. Those boundaries live in the transcript though, not in stored rules, so if context compaction drops the message, the boundary goes with it. For a hard guarantee, write a deny rule.
How it differs from --dangerously-skip-permissions
--dangerously-skip-permissions is the same thing as --permission-mode bypassPermissions. It does exactly what the name promises: disables prompts and safety checks, tool calls execute immediately. That includes writes to protected paths like .git, .claude, .vscode, and .idea, which every other mode refuses to auto-approve. As of v2.1.126 that protected-path behaviour is on by default in bypass; earlier versions still prompted.
Two things still bite even in bypass. Explicit ask rules force a prompt. And a circuit breaker still stops on rm -rf / and rm -rf ~, catching the worst model-error cases against your filesystem root and home directory.
That's the whole safety story for bypass: two hardcoded patterns. Here's the comparison that the Reddit threads never make cleanly.
Auto mode's guard is an ML classifier. Context-aware and smart, but less predictable. It can false-positive on legitimate work and block something you actually wanted, which is annoying but recoverable.
Bypass's guard is a deterministic circuit breaker. Completely predictable, and it only knows two patterns. Everything else risky sails straight through. It false-negatives on basically everything that isn't rm -rf /.
Neither one is strictly safer. They fail in opposite directions: auto mode interrupts you when it's wrong, and bypass stays silent when it's wrong. Pick based on which failure you'd rather have.
Where sandboxing fits, which is the real answer for the bypass crowd
If you reached for bypass to kill the prompts, auto mode isn't actually your answer. Sandboxing is.
In Anthropic's own internal usage, sandboxing cut permission prompts by 84% while keeping a real security boundary. That's their reported figure from internal use, not an independent benchmark, and they haven't published the methodology, so treat the number as directional. The mechanism is solid regardless: filesystem isolation so the agent can only touch directories you name, network isolation so it can only reach servers you approve. Under the hood it's macOS seatbelt and Linux bubblewrap enforcing this at the OS level, including any subprocess a command spawns.
The difference from bypass is the part that should land. Bypass removes the boundary and saves you the prompts. A sandbox saves you ~84% of the prompts and keeps a boundary that survives a successful prompt injection. A compromised agent inside a sandbox still can't read your SSH keys or phone home. Run /sandbox to set it up.
The decision table
Four tools, one decision. Pick by what you're protecting and what kind of friction you're trying to kill.
| Mode | Use it when | The tradeoff |
|---|---|---|
| auto | You want long autonomous stretches on a task whose direction you trust. Good for grinding through a big refactor without prompt fatigue. | Occasional false-positive blocks on legit work. Recoverable, just annoying. |
| sandbox | You want autonomy and a real boundary. This is the bypass crowd's actual answer. | Most of the prompt relief, none of the security model thrown out. |
| bypass | There's genuinely nothing to protect: isolated container or VM, no network, nothing on the host worth losing. | No boundary at all. Fine only because there's nothing to lose. |
| allowlist | Your friction is a handful of predictable commands you run constantly. | Pre-approve npm test and friends with allow rules, skip the heavier machinery. |
One honest note on the full picture
If you've run claude --help, you've seen there are six --permission-mode values, not the two or three the blog posts discuss: default, plan, acceptEdits, auto, dontAsk, and bypassPermissions.
dontAsk is the locked-down one: it auto-denies anything that would otherwise prompt, so only your pre-approved allow rules and read-only commands run. It's built for CI pipelines and restricted environments where you define upfront exactly what Claude may do, and want zero interactivity. Different job from auto mode entirely. Auto mode opens everything with a classifier watching; dontAsk closes everything except what you whitelisted.
Auto mode is everything-on with a smart guard. Bypass is everything-on with no guard but two tripwires. Sandbox is the boundary most people who reached for bypass actually wanted. dontAsk and allowlists are for the locked-down end. The right pick comes down to which guard you want.