Claude Lessons / Guides

Claude Code Auto Mode Explained: The New Default, What It Blocks, and How to Stay in Control

Claude Lessons team · Updated August 18, 2026

On August 14, 2026, auto mode became the default permission mode for new Claude Code sessions on Pro, Max, and Team plans. If you opened a session this week and noticed it stopped asking you to approve every command, this is why. Auto mode replaces the approve-approve-approve loop with a second model — a classifier — that reviews each risky action before it runs and blocks the dangerous ones. It is neither "Claude does whatever it wants" nor a rebranded --dangerously-skip-permissions. This guide covers what actually changed, how the classifier decides, what it blocks and what sails through, and the three mechanisms (ask rules, stated boundaries, autoMode config) that let you run hands-off without giving up the boundaries you care about.

What auto mode actually is

Every Claude Code session runs in a permission mode that decides what Claude may do without asking. In Manual mode (config value default), most file edits, shell commands, and network calls stop and wait for your approval. Auto mode changes who does the reviewing: instead of prompting you, each risky tool call is routed through a separate classifier model that checks it before execution and blocks anything irreversible, destructive, or aimed outside your environment.

Three details define it more precisely than "fewer prompts":

• It's a second model, not a rule list. The classifier (Claude Sonnet 5 by default, regardless of your session's /model) reads your messages, the pending action, and your CLAUDE.md, then judges the action in context. "Push this branch" and "push this branch containing a file that looks like leaked credentials" get different verdicts even though the command is identical.
• Safe operations never reach it. Read-only actions and file edits inside your working directory are auto-approved directly (writes to protected paths like .git/ and .claude/ excepted). The classifier's attention — and its latency — is spent on shell commands and network operations, where the risk actually lives.
• Blocks aren't dead ends. When the classifier blocks an action, Claude is told and usually finds a safer route or asks you directly for the go-ahead. Denied actions are also logged in /permissions under Recently denied, where pressing r retries one with your manual approval.

Auto mode also nudges Claude to keep working instead of pausing for clarifying questions — which is exactly what you want for a two-hour refactor and exactly what you should account for when writing the initial prompt: the spec you give up front carries more weight when there are fewer mid-task check-ins.

The default change: who it affects, who it doesn't

The switch wasn't arbitrary. Anthropic's data showed that manual review had become theater for most users: 97% of permission prompts get approved, and in a 1,053-person controlled study, people caught a deliberately dangerous command only 13.6% of the time — dropping to roughly 5% after fifty prompts in a session — while the classifier caught 89% of the same commands. When a review step is approved reflexively, it stops being a review step. The new default moves the review to something that doesn't get tired.

Who starts in auto mode now, and who doesn't:

The built-in auto default requires Claude Code v2.1.228 or later (v2.1.233+ on native Windows); older versions keep Manual as the built-in default. The very first session after an install or upgrade also starts in Manual. And the classifier's token overhead is no longer billed on Pro, Max, and Team plans — on Enterprise and API-billed providers it still counts toward usage.

How the classifier decides

Each action goes through a fixed decision order. The first matching step wins:

1. Your permission rules resolve first. deny rules block outright — the classifier is never consulted and can't override them. Explicit ask rules force a prompt to you, even in auto mode. Narrow allow rules (like Bash(npm test)) approve instantly.
2. Read-only actions and working-directory edits auto-approve, except writes to protected paths (.git/, .claude/, shell rc files, lockfile configs like .npmrc), which route to the classifier instead.
3. Everything else goes to the classifier — shell commands, network calls, pushes, deploys, MCP tool calls.
4. On a block, Claude gets told and adapts. The reason is usually the fixed text "Blocked by classifier"; Claude tries an alternative or asks you.

Two design choices are worth understanding because they explain behavior you'll observe. First, entering auto mode suspends your broad allow rules. A rule like Bash(*), a wildcarded interpreter like Bash(python:*), or a blanket Agent rule would let arbitrary code skip the classifier entirely, so those are set aside while auto mode is active (your settings files aren't modified; the rules return the moment you switch modes). Narrow rules carry over. If you want everything screened, including commands your narrow allow rules would pass, set autoMode.classifyAllShell to true.

Second, the classifier never sees tool results. It reads your messages, Claude's pending tool calls, and your CLAUDE.md — but the contents of files and web pages Claude read are stripped from its view. That means hostile text in a README can't sweet-talk the reviewer, which is why auto mode doubles as a prompt-injection defense: in a third-party evaluation of 72 held-out injection scenarios run 10 times each, none of the 720 attempts succeeded against current Claude models running auto mode. A separate server-side probe additionally scans incoming tool results and warns Claude when content looks like an injection attempt.

A useful corollary: because the classifier reads CLAUDE.md, a project rule like "never force push" or "never touch the migrations folder" steers both Claude and its reviewer at once. Writing good CLAUDE.md rules just became a permissions tool — see our CLAUDE.md best practices guide.

What gets blocked, what sails through

The full rule list is long (print it yourself with claude auto-mode defaults), but the shape of it fits in a table. The classifier's organizing question is: is this action irreversible, destructive, or leaving the environment I trust?

A few blocks deserve special mention because they close paths people don't think of: posting a comment that is itself a command to automation (/deploy, atlantis apply), repointing an API base URL or registry mirror at a third-party host, changing where pushes go with git remote set-url unless you named the new remote, opening a reverse shell that exposes a local service to the internet, launching another agent with --dangerously-skip-permissions, and sending keystrokes to Claude Code's own terminal pane (which would let it drive its own approvals). The rules read like a catalog of postmortems, which is roughly what they are: at Anthropic, where auto mode is the internal default, the classifier has blocked a fallback that would have published an internal report to a public code-sharing site, a mass process kill across ~2,000 pods, and a read-only-billing request that reached for a root admin role.

One boundary that surprises people in a good way: the classifier considers repository visibility. Pushing confidential material to your private repo is fine; the same content heading to a public repo, or live API data (emails, account IDs) landing in a public PR body, gets blocked unless you explicitly named it. The push allowance is also branch-aware — a branch named production or gh-pages is judged as the deploy target it is, not as just another branch.

When auto mode falls back to asking you

Auto mode is designed to degrade into Manual, not to fail open. The mechanics:

• 3 blocks in a row, or 20 total in a session, and auto mode pauses — Claude Code resumes prompting you like Manual mode. Approving the prompted action resumes auto mode. The thresholds aren't configurable; any allowed action resets the consecutive counter.
• Every denial is reviewable. Open /permissions → Recently denied to see what was blocked. Press r on an entry to mark it for retry; Claude Code tells the model it may re-attempt that call with your blessing.
• Repeated denials are a config smell, not a fight. If the classifier keeps blocking pushes to your company's GitHub org or writes to your team's S3 bucket, it's missing context about what "internal" means for you. That's what autoMode.environment is for.
• Headless runs never hang. A claude -p run has no prompt to fall back to; blocked actions simply don't run and Claude keeps working around them.

Setting boundaries that hold

The most common auto mode question is some version of: "I want hands-off execution, but never let it push without me." There are three mechanisms, with different strength guarantees. Match the mechanism to how firm the boundary needs to be.

The human-checkpoint-before-push recipe, in your settings file:

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

Conversational boundaries are more capable than they sound — "wait until I review before deploying" blocks matching actions even where the default rules would allow them, and Claude's own judgment that your condition was met does not lift the boundary; only your later message does. But they live in the transcript, and long sessions compact. For anything you'd be upset to lose, put it in an ask or deny rule instead. (How compaction works and what survives it is covered in the context management guide.)

Configuring the classifier for your environment

Out of the box, the classifier trusts exactly two things: your working directory and the repo's configured remotes (as of session start — a remote added mid-session isn't trusted). Everything else is treated as a potential exfiltration target. That conservative default is right for a personal laptop and wrong for a company, which is what the autoMode settings block fixes:

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Organization: Acme Corp. Primary use: software development",
      "Source control: github.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts",
      "Trusted internal domains: *.corp.acme.com, api.internal.acme.com",
      "Key internal services: Jenkins at ci.acme.com, Artifactory at artifacts.acme.com"
    ]
  }
}

Things to know before you edit:

• Entries are prose, not patterns. Write them the way you'd describe your infrastructure to a new engineer. The classifier reads them as natural-language rules.
• Keep "$defaults" in the array. It splices the built-in entries in at that position. Omitting it replaces the entire default list for that section — including, for soft_deny, the force-push and curl | bash rules. Only do that deliberately.
• Location matters, for a security reason. The classifier reads autoMode from ~/.claude/settings.json, managed settings, and the --settings flag — deliberately not from the project's .claude/settings.json, because a checked-in repo could otherwise inject its own allow rules into your reviewer.
• You can also tune the rule lists. autoMode.allow adds exceptions (e.g., "deploying to staging is allowed: it resets nightly"), soft_deny adds destructive patterns user intent can still override, and hard_deny adds boundaries nothing overrides. Explicit user intent clears soft denies — asking Claude to "force-push this branch" authorizes exactly that; "clean up the repo" doesn't.

The inspection loop, all from your shell:

# Print the built-in rules as JSON
claude auto-mode defaults

# Print what YOUR session actually uses (settings applied)
claude auto-mode config

# Get AI review of your custom rules for ambiguity and false-positive risk
claude auto-mode critique

# Remove your customizations from ~/.claude/settings.json
claude auto-mode reset

A reasonable rollout order: run with plain defaults; when a routine action gets blocked, add your source control org and key internal services (this resolves the most common false positives); add trusted domains and buckets as blocks come up. For teams standardizing this across an org via managed settings, the deployment side is covered in the Claude Code for teams guide.

Switching modes and opting out

• Mid-session: press Shift+Tab. From auto, the first press lands on Manual; the cycle then runs default → acceptEdits → plan → (optional modes) → back around, with auto slotting in after plan. The status bar shows ⏵⏵ auto mode on while it's active. In VS Code and the desktop app, use the mode selector by the prompt box.
• One session: claude --permission-mode default (or manual, accepted as an alias since v2.1.200).
• Every session: set permissions.defaultMode in ~/.claude/settings.json. One asymmetry to know: a defaultMode of "auto" is honored from user and managed settings but deliberately not from a project's .claude/settings.json — a cloned repo can't switch you into auto mode. Every other mode value works from project settings.
• Organization-wide off switch: permissions.disableAutoMode: "disable" in managed settings removes auto mode from the cycle entirely; --permission-mode auto then starts in Manual.

Auto mode among the other permission modes

The pairing that matters most in practice is plan mode + auto mode. As execution gets more autonomous, the leverage moves to the moments your judgment still applies: the plan approval before work starts, and the diff review after it ends. Plan first, approve into auto mode, review the result. Autonomy in the middle is exactly where it's cheap.

And to be precise about the comparison people actually worry about: auto mode is not bypassPermissions with better marketing. Bypass removes all review; auto mode replaces your habitual click-through with a reviewer that reads every risky call, can't be fatigued at prompt fifty, and blocks the categories — exfiltration, self-escalation, injection-driven actions — that matter most. Anthropic's own head-to-head: the classifier blocked 800 dangerous commands that human reviewers approved; humans blocked 6 it allowed. If your threat model still demands isolation, that's a sandboxing question, not a mode question — see the security best practices guide.

Common mistakes

• Treating auto mode as a safety guarantee. It's a strong statistical layer, not infallibility — Anthropic says as much. For high-stakes changes to production infrastructure, review the actions yourself: switch to Manual for that stretch or gate it with ask rules.
• Reaching for --dangerously-skip-permissions out of habit. A quarter of interactive sessions used to start in bypass mode, mostly to escape prompt fatigue. Auto mode removes the fatigue while keeping a reviewer in the loop. Bypass now has exactly one remaining use case: fully isolated containers.
• Fighting the classifier instead of configuring it. If the same push or upload gets blocked three times, stop rephrasing and add the destination to autoMode.environment. Repeated denials are missing context, not stubbornness.
• Trusting conversational boundaries for critical limits. "Don't touch prod" holds until compaction eats the message that said it. Critical boundaries belong in deny or ask rules, which survive the whole session.
• Keeping stale Bash(*) allow rules and expecting them to work. Broad execution rules are suspended in auto mode by design. If you notice a formerly-instant command now takes a classifier round-trip, that's why — and it's the point.
• Skipping the diff review because "it was supervised." The classifier reviews for danger, not correctness. Wrong-but-safe code sails through, as it should. Your review moved from per-command to per-result; it didn't disappear.

FAQ

What is auto mode in Claude Code?

Auto mode is a permission mode in which Claude Code stops asking you to approve routine actions. Instead, a separate classifier model reviews each risky tool call before it runs and blocks anything irreversible, destructive, or aimed outside your environment — force pushes, curl | bash, production deploys, sending secrets to external endpoints. Reads and ordinary file edits in your working directory skip the classifier entirely. When the classifier blocks something, Claude finds a safer route or asks you directly.

Is auto mode on by default?

Yes, for most people. Since August 14, 2026, new sessions on Pro, Max, and Team plans start in auto mode (Claude Code v2.1.228+, or v2.1.233+ on native Windows). It is not the default for Enterprise plans, Console API keys, claude -p and Agent SDK runs, or sessions on Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry — those still start in Manual. If you had already pinned a different defaultMode, your choice is kept; you may see a one-time prompt asking whether to switch.

Is auto mode the same as --dangerously-skip-permissions?

No. bypassPermissions skips every check — no prompts, no review of any kind. Auto mode replaces your prompts with a second model that inspects each risky action before it runs. In third-party prompt-injection testing, current Claude models in auto mode stopped every attack in the evaluation set; bypass exists precisely to remove that layer. Outside an isolated container, choose auto mode.

How do I turn off auto mode?

Press Shift+Tab to switch mid-session — the first press from auto lands on Manual. To change the default for every session, set permissions.defaultMode to "default" in ~/.claude/settings.json. Organizations can remove auto mode entirely with permissions.disableAutoMode: "disable" in managed settings, which also takes it out of the Shift+Tab cycle.

Does auto mode cost extra tokens?

On Pro, Max, and Team plans, no — Anthropic stopped charging for the classifier's overhead when auto mode became the default. On Enterprise plans and API-billed setups, classifier calls count toward usage: each check sends part of the transcript plus the pending action. Since reads and working-directory edits skip the classifier, the overhead lands mainly on shell commands and network operations. For the broader picture of where session tokens go, see the token usage and costs guide.

Does auto mode work with subagents and agent teams?

Yes, and more thoroughly than most people expect. For subagents, the classifier evaluates the delegated task before the subagent starts, screens each of its actions while it runs, and reviews its full action history when it returns. In agent teams, it also reviews every message agents send each other — and treats one agent's claim that "the user approved this" as untrusted rather than as consent.