I counted once. During a 45-minute refactoring session with Claude Code, I pressed "y" to approve permissions 87 times. That's roughly once every 30 seconds. I wasn't coding. I was babysitting a permission dialog.
On March 24, Anthropic shipped auto mode for Claude Code, and the permission problem is essentially solved. A separate classifier model now evaluates every tool call in real time, auto-approving safe actions and blocking dangerous ones. No manual approvals for file reads. No --dangerously-skip-permissions flag. Just a classifier sitting between Claude and your system, making judgment calls.
Here's how it actually works, what it blocks, and why it matters more than you'd think.
The Problem Was Worse Than You Remember
If you've used Claude Code for anything beyond trivial tasks, you know the friction. The default permission mode requires approval for every tool call. Reading a file? Approve. Searching code? Approve. Running git status? Approve.
The workaround most developers eventually discovered was --dangerously-skip-permissions, which does exactly what the flag name warns: it bypasses every safety check. According to Anthropic's blog post, a significant number of users ended up there simply because the approval loop was unbearable.
There was an allowlist option too. You could register specific tools: claude --allowed-tools "Bash(git diff)" "Bash(git log)". But this was static. The safety of a command depends on context, not on the command itself. rm deleting a temp file is fine. rm targeting your .env is not. A static list can't distinguish between the two.
Post not found or has been removed.
Inside the Classifier
Auto mode introduces a classifier model that intercepts every tool call before execution. When Claude generates a tool invocation, the classifier reviews three things: whether the action stays within the scope of your original request, whether the target is trusted infrastructure, and whether the action might be driven by malicious content embedded in files or web pages (the prompt injection defense).
The classifier runs on Claude Sonnet 4.6 regardless of your main session model. Even if you're on Opus 4.6, the classifier is always Sonnet. This is a deliberate design choice: the classifier fires on every single tool call, so it needs to be fast and cost-effective. Running Opus for classification would add unacceptable latency.
User Request → Claude generates tool call
↓
[Classifier on Sonnet 4.6]
↓
Safe? → Auto-execute (no prompt)
Risky? → Block → Claude redirects
When the classifier blocks an action, it doesn't just stop. It redirects Claude to find an alternative approach. If Claude wanted to run a destructive bash command, the classifier blocks it and Claude attempts the task through a safer path.
Post not found or has been removed.
What Passes, What Doesn't
Read-only operations pass almost universally: file reads, code searches, directory listings, git log, git diff. These are the operations that generated most of the permission fatigue in the first place.
File writes pass when they match your stated intent. "Update the button styles in Header.tsx" gives Claude a clear scope. Modifying that file's Tailwind classes goes through automatically. But if Claude suddenly tries to edit your next.config.js during a styling task, the classifier catches the scope creep.
The classifier consistently blocks mass file deletions, rm -rf patterns, external network requests to unknown endpoints, access to .env files and credentials, git push --force, and anything that looks like it could affect production infrastructure.
The key insight is that this isn't a static ruleset. The classifier reasons about intent. It's asking "does this action make sense given what the user asked for?" rather than "is this command on the approved list?"
The Workflow Difference
Before auto mode, here's what a typical refactoring session looked like: ask Claude to extract a component, approve file read, approve another file read, approve code search, approve file write, approve another file read, approve test file creation, approve test execution. Eight approvals for one task.
After auto mode, it's: ask Claude to extract a component, come back five minutes later to a completed PR-ready diff. The reads, writes, and test runs all happened automatically because they stayed within scope.
Enabling auto mode is one command:
claude --enable-auto-mode
You can also toggle it mid-session with /permissions. Anthropic's docs recommend running in isolated environments (containers, VMs) as an additional safety layer, which is honest about the classifier's limitations.
Token usage and latency increase slightly since the classifier processes every tool call. In my testing, the overhead added roughly 200-400ms per tool call. Barely noticeable when the alternative was waiting for me to context-switch back to the terminal.
Post not found or has been removed.
Auto Mode + Hooks + Agents
Auto mode gets more powerful when combined with two other recent Claude Code features. Hooks let you run custom scripts before and after tool calls, so you can auto-format code after every write or run linting checks before commits. Agents enable parallel task execution, splitting independent work across multiple Claude instances.
The three together create a workflow where you describe what you want, and Claude Code handles execution end-to-end. Hooks enforce your standards, auto mode removes friction, and agents parallelize independent work.
This is available now as a research preview on Team plans. Enterprise and API access is coming soon. It requires Sonnet 4.6 or Opus 4.6, with no support yet for Haiku, Claude 3 models, or third-party providers like AWS Bedrock or Google Vertex.
What's Still Missing
The classifier's decision criteria aren't transparent. When an action gets blocked, you don't get a detailed explanation of why. You learn the boundaries by trial and error. For a tool that's supposed to reduce friction, opaque blocking decisions create a different kind of friction.
There's also the question of adversarial robustness. The classifier runs on Sonnet 4.6. If someone crafts a file with embedded instructions designed to fool the classifier, how well does it hold up? Anthropic hasn't published adversarial testing results yet.
And the "use isolated environments" recommendation is telling. It means Anthropic knows the classifier will make mistakes, and they're asking you to limit the damage when it does.
Still, the tradeoff is clearly worth it. Permission fatigue was pushing developers toward --dangerously-skip-permissions, which is worse than any classifier failure mode. Auto mode is the first real middle ground.
The best permission system is one that disappears. Auto mode isn't perfect, but 87 fewer "y" presses per session is hard to argue with.
Full Korean analysis on spoonai.me.
Sources:
Top comments (0)