Claude Code Auto Mode: Safe Uninterrupted Development

Every Claude Code user hits the same wall. You're deep in a refactor, Claude needs to run npm test, and the permission prompt yanks you out of flow state. Click approve. Claude reads another file. Click approve. It writes a migration. Click approve. Thirty prompts later, you're rubber-stamping everything without reading it.

The alternative until now was --dangerously-skip-permissions, which skips all safety checks entirely. That works in containers. On your actual machine with SSH keys, environment secrets, and git credentials? Not a reasonable option.

Auto mode, launched March 24, 2026, fills the gap. It uses a background AI classifier to evaluate each tool call before execution, blocking actions that look dangerous while letting safe operations proceed without prompting. Think of it as an AI security reviewer sitting between Claude and your system, making the approval decisions you would make, at machine speed.

What Auto Mode Actually Does

Auto mode is a new permission mode that sits between default (approve everything manually) and bypassPermissions (no checks at all). When enabled, Claude executes actions without showing permission prompts. But before each action runs, a separate classifier model reviews the conversation context and the pending action to decide whether it should proceed.

The classifier checks for three categories of risk:

1. Scope escalation: Is Claude doing something beyond what you asked for?
2. Untrusted infrastructure: Is the action targeting systems the classifier doesn't recognize?
3. Prompt injection: Does the action look like it was driven by hostile content Claude encountered in a file or web page?

Safe actions proceed automatically. Risky ones get blocked, and Claude receives the reason so it can try an alternative approach. You keep working. The classifier keeps watching.

How the Classifier Works

The classifier runs on Claude Sonnet 4.6, regardless of which model your main session uses. It receives your user messages and tool calls as input, with Claude's own text and tool results stripped out. This design is intentional: because tool results never reach the classifier, hostile content embedded in files or web pages cannot manipulate the classifier's decisions directly.

The classifier also receives your CLAUDE.md content, so project-specific instructions factor into its allow and block decisions. Unlike your static permission rules, which match tool names and argument patterns, the classifier reads prose descriptions. It reasons about each action in context rather than matching syntax.

The Decision Order

Each action follows a fixed evaluation sequence. The first matching step wins:

This means your existing permission rules still take priority. If you have Bash(npm test) in your allow list, it executes instantly without a classifier call. If you have Bash(rm -rf *) in your deny list, it gets blocked before the classifier sees it.

What Happens to Broad Allow Rules

Here is the critical detail most users will miss: on entering auto mode, Claude Code drops broad allow rules that grant arbitrary code execution. Rules like Bash(*), Bash(python*), Bash(node*), and any Agent allow rule get temporarily removed.

Why? These rules would auto-approve the exact commands most capable of causing damage before the classifier ever evaluates them. If Bash(*) stayed active, every shell command would bypass the classifier entirely, defeating the purpose.

Narrow rules like Bash(npm test) or Bash(git status) carry over. The dropped rules restore when you leave auto mode.

What Gets Blocked vs. Allowed

The classifier operates on a trust boundary model. It trusts your local working directory and, if you're in a git repo, that repo's configured remotes. Everything else is treated as external until you tell it otherwise.

Blocked by Default

Allowed by Default

To see the complete default rules as the classifier receives them, run:

claude auto-mode defaults

If the classifier blocks something routine for your team, like pushing to your org's repo or writing to a company storage bucket, that is because the classifier does not know those are trusted. Administrators can configure trusted infrastructure through the autoMode.environment setting. See the official docs on configuring the auto mode classifier for the full setup.

How to Enable Auto Mode

Prerequisites

Auto mode requires:

• Claude Code Team plan (Enterprise and API support rolling out shortly)
• Claude Sonnet 4.6 or Claude Opus 4.6 (not available on Haiku, claude-3 models, or third-party providers like Bedrock or Vertex)
• Admin enablement: an admin must enable auto mode in Claude Code admin settings before users can turn it on

CLI

Start a session with auto mode available, then cycle to it:

claude --enable-auto-mode

Press Shift+Tab to cycle through modes: default -> acceptEdits -> plan -> auto. The current mode appears in the status bar.

You can also start directly in auto mode:

claude --permission-mode auto

VS Code

1. Open the Claude Code extension settings
2. Enable Allow dangerously skip permissions (this unlocks auto mode in the UI)
3. Click the mode indicator at the bottom of the prompt box
4. Select Auto from the dropdown

Desktop App

1. Enable auto mode in Desktop settings
2. Use the mode selector next to the send button
3. Select Auto from the dropdown

Auto mode is disabled by default on the Claude desktop app. You need to enable it explicitly in settings first.

Non-Interactive Mode

Auto mode works with the -p flag for scripted runs:

claude -p "refactor the auth module" --permission-mode auto

If the classifier triggers a fallback (see below), non-interactive mode aborts the session since there is no user to prompt.

How Auto Mode Handles Subagents

For teams using autonomous agent loops or multi-agent architectures, subagent handling matters. Auto mode evaluates subagents at three points:

At spawn: The classifier evaluates the delegated task description before the subagent starts. A task like "delete all remote branches matching this pattern" gets blocked before the subagent ever executes.

During execution: Inside the subagent, auto mode runs with the same block and allow rules as the parent session. Any permissionMode the subagent defines in its own frontmatter is ignored. Each tool call goes through the classifier independently.

On return: When the subagent finishes, the classifier reviews its full action history. A subagent that looked benign at spawn could have been compromised mid-run by content it read. If the return check flags a concern, a security warning gets prepended to the subagent's results so the main agent can decide how to proceed.

This three-checkpoint approach means you do not need to trust subagents implicitly. The classifier watches them the same way it watches the main session.

Auto Mode vs. Other Permission Modes

Here is how auto mode compares to every other permission mode Claude Code offers:

The key tradeoff: auto mode costs more tokens and adds latency per checked action, but eliminates the flow-destroying permission prompts that make default mode painful for extended sessions.

When to Use Auto Mode

Use auto mode when:

• You're running long tasks where constant approval prompts break your concentration
• You trust the general direction of the work but want a safety net against mistakes
• You're using agent loops where no human is available to approve every step
• You want something safer than bypassPermissions for non-containerized development

Do not use auto mode when:

• You're making changes to production infrastructure (the classifier blocks these by default, and for good reason)
• You're working on unfamiliar code where you want to review every action
• You need deterministic, auditable permission control (use dontAsk with explicit allow rules instead)
• You're extremely cost-sensitive (classifier calls add token usage)

When Auto Mode Falls Back

The fallback design prevents false positives from derailing your session. If the classifier blocks an action 3 times in a row or 20 times total in one session, auto mode pauses and Claude Code resumes prompting for each action manually.

These thresholds are not configurable.

When the fallback triggers:

• CLI: A notification appears in the status area. Approving the prompted action resets the denial counters, so you can continue in auto mode afterward.
• Non-interactive mode (-p flag): The session aborts, since there is no user to prompt.

Repeated blocks usually mean one of two things: the task genuinely requires actions the classifier is designed to stop, or the classifier is missing context about your trusted infrastructure. If blocks look like false positives, use /feedback to report them. If the classifier does not recognize your repos or services, have an administrator configure trusted infrastructure in managed settings.

Defense in Depth: Auto Mode in Your Security Stack

Auto mode is one layer. By itself, it provides more protection than bypassPermissions but is not as thorough as manually reviewing each action. The strongest security posture combines multiple layers:

Layer 1: Permission rules. Your settings.json allow/deny rules resolve before the classifier runs. Use them for deterministic control over specific tools and commands.

Layer 2: Auto mode classifier. Evaluates everything that permission rules do not catch. Reasons about context, not just pattern matching.

Layer 3: Hooks. PreToolUse hooks run custom logic before the permission system. The Permission Hook provides LLM-powered auto-approval with a three-tier system (fast approve, fast deny, LLM analysis). Hooks and auto mode can coexist: hooks run first and can approve, deny, or escalate before the classifier sees the action.

Layer 4: Sandboxing. OS-level sandboxing restricts filesystem and network access at the kernel level. Even if the classifier misses something, the sandbox prevents Bash commands from reaching resources outside defined boundaries. This is especially important because the classifier evaluates intent, while the sandbox enforces hard boundaries.

Layer 5: Self-validating agents and stop hooks. These ensure agents complete tasks correctly and do not drift from their assigned scope, adding another verification layer on top of permission controls.

Each layer catches what the others miss. That is what defense in depth means in practice.

Limitations: What You Should Know

Auto mode launched as a research preview. Be honest about what that means:

• It does not guarantee safety. The classifier can miss risky actions when user intent is ambiguous or Claude lacks environment context. It can also block benign actions (false positives).
• It costs more. Classifier calls count toward your token usage. Each checked action sends a portion of the conversation transcript plus the pending action to the classifier. The extra cost comes mainly from shell commands and network operations, since read-only actions and file edits in your working directory skip the classifier.
• It adds latency. Each classifier check adds a round trip before the action executes. For rapid sequences of shell commands, this overhead is noticeable.
• Limited availability. Currently Team plan only (research preview). Enterprise and API support is rolling out shortly. Requires Sonnet 4.6 or Opus 4.6. Not available on Haiku, claude-3 models, or third-party providers.
• Not a replacement for review on sensitive operations. Use it for tasks where you trust the general direction. For anything touching production, credentials, or shared infrastructure, manual review remains the right choice.

The classifier will improve over time. Use /feedback to report false positives and missed blocks. Every report helps calibrate the system.

What's Next

Auto mode changes the daily workflow for Claude Code users on Team plans. The permission dilemma that forced you to choose between safety and speed now has a middle path.

To build a complete security setup around auto mode:

• Set up permission rules for deterministic control over specific tools
• Configure hooks for custom permission logic beyond what the classifier handles
• Enable sandboxing for OS-level enforcement as a hard backstop
• Review the settings reference for all permission-related configuration options
• Explore autonomous agent loops to take full advantage of reduced prompting in long-running tasks

The permission prompt is no longer the bottleneck. The classifier is watching. You can get back to building.