Claude Code auto mode: a safer way to skip permissions
Published: Mar 25, 2026
By: John Hughes
Claude Code users approve 93% of permission prompts. The team built classifiers to automate some decisions, increasing safety while reducing approval fatigue. The article explains what it catches and what it misses.
Overview
By default, Claude Code asks users for approval before running commands or modifying files. This keeps users safe but leads to approval fatigue over time, where people stop paying close attention to what they're approving.
Users previously had two solutions for avoiding fatigue: a built-in sandbox where tools are isolated to prevent dangerous actions, or the --dangerously-skip-permissions flag that disables all permission prompts entirely, which is unsafe in most situations. Sandboxing is safe but high-maintenance, while bypassing permissions is zero-maintenance but offers no protection. Manual prompts sit in the middle, and in practice users accept 93% of them anyway.
Figure 1 positions the permission modes by task autonomy and security. Dot colour indicates maintenance friction. Auto mode targets high autonomy at low maintenance cost; a dashed arrow shows security improvement over time as classifier coverage and model judgment get better.
Internal Incident Examples
The team maintains an internal incident log focused on agentic misbehaviors. Past examples include deleting remote git branches from a misinterpreted instruction, uploading an engineer's GitHub auth token to an internal compute cluster, and attempting migrations against a production database. Each resulted from the model being overeager, taking initiative beyond what the user intended. This pattern was documented in the Claude Opus 4.6 system card (§6.2.1 and §6.2.3.3).
Auto mode is a new mode for Claude Code that delegates approvals to model-based classifiers — a middle ground between manual review and no guardrails. The goal is to catch dangerous actions that aren't aligned with user intent while letting the rest run without approval prompts.
How it works
Auto mode uses two layers of defense: one for what Claude reads, one for what Claude does.
Input layer: A server-side prompt-injection probe scans tool outputs (file reads, web fetches, shell output, external tool responses) before they enter the agent's context. When content looks like an attempt to hijack behavior, the probe adds a warning to the agent's context telling it to treat the content as suspect and anchor on what the user actually asked for.
Output layer: The transcript classifier (running on Sonnet 4.6) evaluates each action against decision criteria before it executes, acting as a substitute for a human approver. The classifier runs in two stages: a fast single-token filter deciding 'yes' to block or 'no' to allow, followed by chain-of-thought reasoning only if the first filter flags the transcript. Because most actions clear the first stage, reasoning tokens are spent only where needed. The classifier sees only user messages and the agent's tool calls; Claude's own messages and tool outputs are stripped out, making it reasoning-blind by design.
Figure 2 shows the system architecture: the transcript classifier gates tool calls; the prompt-injection probe screens tool results. Subagents run the same pipeline recursively, with handoff classifiers at delegation (can deny) and at return (warns only).
Threat model
An agent might take a dangerous action for four reasons:
Overeager behavior. The agent understands the user's goal and is genuinely trying to help but takes initiative beyond what the user would approve. For example, it uses a credential it happened to find or deletes something it judged to be in the way. This is tricky to catch because there's no hostile reasoning — the action looks like reasonable problem-solving applied past the boundary of what the user authorized.
Honest mistakes. The agent misunderstands the blast radius. For example, it thinks a resource is test-scoped when it's shared, or a branch is its own when it isn't.
Prompt injection. Instructions planted in a file, webpage, or tool output hijack the agent, redirecting it from the user's task toward the attacker's.
A misaligned model. Misalignment occurs when the agent pursues a goal of its own. This isn't currently seen in practice but is evaluated carefully for every model release.
In all four cases, the defense is to block the action. The classifier is tuned to overeager behavior and honest mistakes, as there are specific examples from internal model testing, but the defense applies regardless of which threat produced the action.
Threat model examples (adapted from internal incident log):
Scope escalation. A user asked to "clean up old branches." The agent listed remote branches, constructed a pattern match, and issued a delete. This would be blocked since the request was vague, the action irreversible and destructive, and the user may have only meant local branches.
Credential exploration. An agent hit an auth error partway through a task. Rather than asking for permission, it began systematically grepping through environment variables and config files for alternative API tokens. These credentials could be scoped for a different task, so this is blocked.
Agent-inferred parameters. A user said "cancel my job." The agent queried the cluster, picked the closest match by name similarity, and tried to delete it. This is blocked since the specific target may not have been what the user intended.
Sharing via external service. An agent wanted to share a script for debugging and constructed a GitHub Gist command. This is blocked as data exfiltration since the user may consider the contents confidential.
Safety-check bypass. A deploy command failed a pre-check; the agent retried with a skip-verification flag. This is blocked since it could impact shared infrastructure.
How permission decisions work
Tier 1: Built-in safe-tool allowlist and user settings
A fixed allowlist includes tools that can't modify state, including file reads, text and file-pattern search, code navigation, todo and plan-mode transitions. Users can also configure always-allow rules for specific tool patterns. One exception: on entering auto mode, permission rules known to grant arbitrary code execution are dropped, including blanket shell access, wildcarded script interpreters (python, node, ruby, and similar), and package manager run commands. This is best-effort based on real-world usage and any list will inevitably be incomplete. Narrow rules ("allow running code formatters") carry over, but broad interpreter escapes don't.
Tier 2: In-project file operations
File writes and edits inside the project directory are allowed without a classifier call. Routine coding doesn't pay classifier latency; in-project edits are reviewable via version control.
Tier 3: Transcript classifier
The transcript classifier sees everything else, including shell commands, web fetches, external tool integrations, subagent spawns, filesystem operations outside the project directory. Stage 1 is a fast single-token filter instructed to err toward blocking; if it flags, stage 2 re-evaluates with chain-of-thought reasoning to reduce false positives.
The classifier decision criteria
The classifier's prompt is a fixed template with three customizable slots inserted into the middle. The fixed parts handle interpretive work — how to determine what an action does, how to read user authorization, the classification process itself — and are the same for everyone. The slots define the policy: what counts as trusted in your environment, what categories to block, what exceptions to carve out. Good defaults ship out of the box. Users can start using auto mode immediately and extend configuration iteratively. Running claude auto-mode defaults shows the full list.
The fixed template
Evaluation rules tell the classifier how to look for dangerous commands. The principle is to evaluate real-world impact rather than just surface text. If the agent writes a payload to a file and then runs it, the classifier evaluates the payload. If a chain of commands is joined with &&, the whole chain is one action. If the agent writes a Python script assembling a shell command, the classifier evaluates the assembled command from the transcript context before allowing execution.
User intent rules tell the classifier how to read authorization. This is where the overeager-behavior defense lives. The classifier has to decide whether the action is something the user authorized, not just related to the user's goal. The classifier is deliberately conservative: what is authorized is established; everything the agent chooses on its own is unauthorized until the user says otherwise. For example, "clean up my branches" doesn't authorize a batch delete, and "can we fix this?" would be considered a question, not a directive.
The template includes a step-by-step classification process: check the action against block rules, then allow exceptions, followed by user intent, before ultimately making a decision.
The customizable slots
The "environment" defines the trust boundary — which domains, cloud buckets, source-control orgs, and internal services count as "inside" versus "external." By default, the only thing trusted is the git repo currently in use. Users can customize this so the classifier can identify their trusted infrastructure (e.g. GitHub org, cloud buckets, or internal API). Anything outside this boundary could be an exfiltration risk.
Block rules default to more than twenty rules, falling into these groups:
- Destroy or exfiltrate. Cause irreversible loss by force-pushing over history, mass-deleting cloud storage, or sending internal data externally.
- Degrade security posture. Make the system harder to monitor or defend by disabling logging, installing persistence like SSH keys or cronjobs, or modifying the agent's own permission config.
- Cross trust boundaries. Act on things the agent has no basis to trust, like running code cloned from external repos, scanning credential stores for usable tokens, or sending data to a service the user never specified.
- Bypass review or affect others. Skip safeguards on shared infrastructure by pushing directly to main, running production deploys, or modifying shared resources or jobs the agent didn't create.
Allow exceptions are mandatory carve-outs where a block rule technically matches but the action is benign. The default is narrow, including installing packages already declared in the repo's manifest, standard credential flows, and pushing to the session's working branch.
All three slots ship with conservative defaults so users can start without writing anything.
Results
The full pipeline was evaluated on three different datasets:
- Real internal traffic (n = 10,000). Actual Claude Code tool calls from Anthropic employees.
- Real overeager actions (n = 52). Curated from sessions where an employee denied the action or it was flagged post-hoc. Small because it requires Claude attempting something dangerous in a real session, captured and labeled.
- Synthetic data exfiltration (n = 1,000). Generated attempts including HTTP POSTs of sensitive data, git pushes to untrusted remotes, and credentials embedded in URLs; many use obfuscation.
Two metrics are reported. False-negative rate (FNR) is the fraction of dangerous actions the classifier lets through; false positive rate (FPR) is the fraction of benign actions it blocks. A perfect classifier scores zero on both. Stage 1 is fast and cheap, tuned for low FNR at the cost of high FPR. Stage 2 is more expensive, runs only on what stage 1 flagged, cleans up false positives but lets a few more dangerous actions through.
Table 1: Classifier performance by stage
| Real traffic (n=10,000) | Real overeager (n=52) | Synthetic exfil (n=1,000) | |
|---|---|---|---|
| Stage 1 (fast filter) | 8.5% FPR | 6.6% FNR | 1.8% FNR |
| Stage 1→Stage 2 (full pipeline) | 0.4% FPR | 17% FNR | 5.7% FNR |
Stage 2 runs only on actions stage 1 flags, so the second row reflects the deployed pipeline end to end: FPR drops from 8.5% to 0.4%, at the cost of some recall.
The 17% false-negative rate on real overeager actions is described as the honest number. The agent was trying to solve the user's problem and tried to execute a dangerous command past what was authorized.
In the majority of misses examined, the classifier correctly identifies the danger — it sees the force-push, the deletion, the infrastructure change. What it gets wrong is whether a real consent signal in the session actually covers this action. "Clean up the PR" was said by the user, but it doesn't name force-pushing. A similar action was approved earlier, but one approval isn't a pattern. The classifier finds approval-shaped evidence and stops short of checking whether it's consent for the blast radius. Prompt-engineering efforts haven't found a fix that doesn't cost more than it gains.
Whether 17% is acceptable depends on what you're comparing against. If running --dangerously-skip-permissions, this is a substantial improvement. If manually approving every action carefully, it's arguably a regression — trading your own judgment for a classifier that sometimes makes mistakes. Auto mode is meant for the first group, and for tasks where the second group's approval overhead isn't worth the marginal safety. It is not a drop-in replacement for careful human review on high-stakes infrastructure.
Design decisions
Why assistant text and tool results are stripped
Assistant text is stripped so the agent can't talk the classifier into making a bad call. The agent could generate persuasive rationalizations, such as suggesting something is safe because the user implicitly approved it earlier, or that a target is agent-owned. The goal is for the classifier to judge what the agent did, not what the agent said.
Stripping tool results is the primary prompt-injection defense, since tool outputs are where hostile content enters the context. The classifier rarely needs them. If the agent reads a file saying to post .env to a URL for validation and then issues the POST, the classifier never sees the file but doesn't need to — a POST of env vars to an external URL fails against user intent regardless of what prompted it. There is a tradeoff in provenance: if the user never named "job abc123," the classifier can't tell whether the agent pulled it from a query or fabricated it. That cost is accepted for injection robustness.
Figure 3 shows what the classifier sees: assistant prose, tool-call descriptions, and tool outputs are stripped; only user messages and the executable payload remain.
This wasn't solely a first-principles choice; alternatives were evaluated. Including assistant messages and tool results caused a drop in performance on the overeagerness testset, likely because a shorter transcript is easier to read and leaves less room for the agent's framing to color the decision. A tool-calls-only variant had the lowest false-negative rate but lost the user-intent anchor, blocking actions the user had plainly asked for. User messages plus tool calls is where they landed.
Being reasoning-blind has a useful side effect: action-level blocking is orthogonal to chain-of-thought monitoring. A model that conceals misaligned reasoning can still be caught if the resulting action trips a block rule; a model whose actions look benign but whose reasoning reveals intent would be caught by CoT monitoring. The two are complementary.
Two-stage classification: efficiency and recall
A single-stage classifier faces a direct performance/cost trade-off. Splitting into two stages with different levels of caution breaks this trade-off. Figure 4 illustrates the pipeline: allowlisted tools skip straight to execution; everything else goes to the classifier. Stage 1 is a fast filter tuned to cautious; only what it flags escalates to stage 2 with reasoning. Denials return to the agent with the reason, allowing retries up to a limit. After execution, the PI probe screens the result before the agent sees it.
The key design choice is how stage 1 is tuned. Its final instruction tells it to "err on the side of blocking" and emit a single yes-or-no decision without reasoning. Stage 1 is tuned to push recall higher than stage 2 on the real overeagerness testset, accepting 8.5% FPR as the cost. Stage 2 sees the same prompt with only the final instruction changed to ask for careful reasoning, reducing FPR to 0.4%. Because the input is identical other than the final instruction, stage 2's prompt is almost entirely cache-hit from stage 1.
Why the prompt-injection probe matters
The transcript classifier's injection defense is structural since it never sees tool results. But the main agent does see tool results, and an injection that hijacks the main agent then has a chance of bypassing the transcript monitor too.
This is why the input-layer probe exists. When content looks like an injection attempt, the probe injects a warning alongside the result, prompting the agent to re-anchor on user intent and treat the content skeptically.
The two layers compound: for an injection to succeed end-to-end, it must evade detection at the input layer, then steer the agent into emitting a tool call that the transcript classifier independently judges as both safe and aligned with user intent. Getting past both, with the second layer blind to the payload that compromised the first, is significantly harder than either alone.
Multi-agent handoffs
The classifier runs at both ends of a subagent handoff: when work is delegated out and when results come back.
The outbound check exists because, without it, the transcript classifier monitoring the subagent may not have the full context to know if the task was originally intended by the user. Inside the subagent, the orchestrator's instruction is the user message, so tasks look fully authorized. It's caught at delegation while still recognizable as an agent choice rather than a user request.
The return check exists because a subagent that was benign at delegation could be compromised mid-run by prompt injection in content it reads. Before results go back to the orchestrator, the classifier reviews the subagent's full action history. If it flags, a security warning is prepended for the agent that started the subagent rather than discarding the results.
Deny-and-continue
Auto mode is meant to replace --dangerously-skip-permissions without bringing back interruptions. When the classifier blocks an action, Claude shouldn't halt and wait for input; it should recover and try a safer approach where one exists.
When the transcript classifier flags an action as dangerous, the denial comes back as a tool result along with an instruction to treat the boundary in good faith: find a safer path, don't try to route around the block. If a session accumulates 3 consecutive denials or 20 total, the model is stopped and the situation is escalated to the human. In headless mode (claude -p) there is no UI to ask the human, so the process is terminated instead.
This is also what makes false positives survivable. A 0.4% FPR sounds small, but if every false positive killed the session it would be a serious usability problem for long-running tasks. Instead, a false positive costs a single retry where the agent gets a nudge, reconsiders, and usually finds an alternative path.
What's next
The team will continue expanding the real overeagerness testset and iterating on improving the safety and cost of the feature. The classifier doesn't need to be flawless to be valuable; the starting point is catching enough dangerous actions to make autonomous operation substantially safer than no guardrails. Users are encouraged to stay aware of residual risk, use judgment about which tasks and environments they run autonomously, and report when auto mode gets things wrong.
Acknowledgements
Written by John Hughes. Special thanks to Alex Isken, Alexander Glynn, Conner Phillippi, David Dworken, Emily To, Fabien Roger, Jake Eaton, Javier Rando, Shawn Moore, and Soyary Sunthorn for their contributions.