Auto mode became Claude Code's default permission system for new sessions on Pro, Max, and Team plans this week — August 14, 2026 — and I want to make the case that the old system it replaces was worse than annoying: it was security theater, and I have the config files to prove I participated in the ritual. My .claude/settings.local.json on this repository contains an allowlist that grew, entry by approved entry, to dozens of rules — php artisan here, vendor/bin/pint there, an ever-longer tail of git commands and fetch domains. Every entry represents a moment I stopped reading and clicked allow. Anthropic's own study puts a number on what that clicking was worth: across 1,053 paid testers, humans caught 13.6% of dangerous commands. The auto mode classifier caught 89%.
I have now run auto mode on real work on this codebase — a production Laravel platform — since it reached general availability. Here is what it actually does, what that study does and does not mean, and the guardrails I keep regardless of mode.
The eras of the permission system, as lived
To understand why auto mode exists, walk the timeline every heavy user walked:
Era one: prompt-per-action. Safe in theory. In practice, approval fatigue set in within days. When you approve dozens of actions per session, approval stops being a decision and becomes a keystroke. The security value of a decision you make without reading is zero; the 13.6% figure is that zero, measured politely.
Era two: the allowlist. Pre-approve safe patterns in settings, get prompted only for the rest. Genuinely better, and still worth doing — but allowlists are static. Mine accreted reactively: each entry added the day some workflow got annoying. Nobody audits their allowlist; it only grows. And the prompts that remain still arrive stripped of the one thing that matters — intent. "Run this bash command?" tells you what; it cannot tell you why, or whether the why was planted by something the agent read.
Era three: --dangerously-skip-permissions. The flag's name is honest. Plenty of experienced users ran it anyway, in containers if they were careful, because era one's ritual made the trade feel rational. The uncomfortable truth of eras one through three: the choice was between friction that produced no safety and no friction with no safety.
Auto mode is era four, and it is the first one that changes the actual mechanism rather than the amount of clicking.
What auto mode actually does
Introduced as a research preview on July 10, 2026 (Team plan first, then Enterprise and API), now generally available and the default for new sessions: in auto mode, Claude makes permission decisions itself, while a separate classifier model reviews every tool call before it runs. The classifier blocks actions that are irreversible or destructive, that escalate beyond what you asked for, that target infrastructure it does not recognize as yours, or that appear to be driven by hostile content the agent read along the way. When something is blocked, Claude can route around it more safely or fall back to asking you — so the prompt you do see in auto mode carries signal instead of noise. Anthropic also decided not to bill the classifier's per-call tokens, which removes the perverse incentive to turn it off for cost.
Three design points deserve emphasis. First, the reviewer is separate from the actor — the agent proposing a command is not the one deciding it is safe, which is the same generator-versus-evaluator separation I build into my own agent pipelines. Second, the classifier sees every call with intent context a human approver never had. Third — and this is the one that should update your threat model — it explicitly targets prompt-injection-driven actions. The scenario where a malicious README steers your agent into exfiltrating an environment file is exactly the class of attack a per-call reviewer can catch and a fatigued human demonstrably does not. I have written before about scanning for exactly these injection risks; auto mode moves part of that defense into the runtime.
Reading the 13.6%-versus-89% study honestly
The comparison favors the classifier for a reason worth naming: it never gets tired. The human number is not a measure of human ability — a security engineer reviewing one suspicious command cold would beat 13.6% easily. It is a measure of human attention under repetition, which is the actual operating condition of a permission prompt. Automating vigilance-under-boredom is precisely the kind of task machines should take from us.
But hold the study to the same standard: 89% is not 100%. Auto mode is a strong probabilistic filter, not a proof system. Eleven percent of dangerous commands slipping past means the classifier is your first line, and architecture — not approval — remains your real defense. Which is why the next section exists.
What I keep, even with auto mode on
My rule set on this repository did not get simpler with auto mode; it got cleaner. The things that survive every permission era:
- Hard policy above the tool layer. My non-negotiable: no direct writes to the production database from an agent session, in any mode. Changes ship as reviewed, transaction-wrapped, idempotent scripts. No classifier verdict overrides this, because the rule exists for reversibility and audit, not just safety.
- Hooks for the non-negotiables. Deterministic checks that run regardless of what any model decides — formatting gates before commits, protected paths. A classifier is probabilistic; hooks are policy as code. Use each for what it is.
- The allowlist, retired from security duty. It still reduces noise for obviously-safe project commands, but I stopped pretending it was a security boundary. That job has better owners now.
- Separation for the truly dangerous. Work touching credentials, billing, or client production systems runs in isolated sessions with minimal reach. The blast-radius principle from secure agent onboarding — grant the least the task needs — is unchanged by auto mode, because limiting what can happen beats classifying what might.
If you want the wider tour of settings worth knowing while you are in the config file anyway, my hidden features guide covers the rest of the surface.
Should you leave the default on?
For most users: yes, and I say that as someone professionally paranoid — I run a security company. Auto mode replaces a mechanism whose measured effectiveness was 13.6% with one measured at 89%, prices the classifier at zero, and reserves your attention for prompts that carry actual signal. Turning it off to click approve again is choosing the ritual over the protection.
The exceptions are real but narrow: regulated environments where a human sign-off per action is a compliance requirement rather than a safety mechanism; and truly hostile experiments — untrusted code, adversarial testing — which belong in containers under stricter modes, not in your main checkout under any mode. For everything between, the honest configuration in 2026 is auto mode on, hooks enforcing your non-negotiables, and architecture doing the heavy lifting it should have been doing all along.
The approve-approve-approve era is over. What it taught us was worth exactly one lesson: security you perform is security you do not have.
Open your own settings.json this week and ask which line in it would have stopped the worst thing an agent could do in that repo. When the honest answer is none of them, that is the conversation I have with teams — bring me your setup and we will fix the blast radius instead of the prompts.
