Claude Code Auto Mode

What Claude Code auto mode actually changes

Auto mode moves routine permission decisions to a classifier, a separate model that judges whether an action fits your request and environment. It checks for actions that exceed your instructions, touch unfamiliar infrastructure, or follow hostile instructions found in content Claude reads. It can still ask you for permission, and it does not guarantee safety. Anthropic's permission-mode documentation describes the current behavior.

It is the middle option between stopping for approvals and removing most permission checks:

For a developer, the benefit is fewer interruptions between editing, testing, and fixing a bounded change. For a team lead, the decision is where human approval must remain. An explicit permissions.ask rule still prompts in auto mode; choosing Auto does not erase that checkpoint.

Who can use auto mode now?

Auto mode is available on all plans when the provider, selected model, and organization settings support it. Team and Enterprise administrators can turn it off through managed settings. The current model requirements are:

Haiku 5.5 auto mode on the second group requires Claude Code 2.1.293 or later. These are session-model requirements, not a promise that the permission classifier uses the same model. Source: current availability requirements.

The built-in default is also different from availability. On supported interactive terminal and VS Code sessions, the current default covers every plan and provider, but an explicit starting mode or organization policy can change it. Eligible organizations with the HIPAA configuration start in Manual by default. A session that cannot use auto falls back to Manual. For unattended claude -p or Agent SDK work on version 2.1.302 or later, no configured mode means Manual (default). Calls needing approval are denied unless an allow rule, hook, SDK canUseTool callback, or --permission-prompt-tool approves them. A CI job that previously relied on implicit auto can therefore stop getting its commands approved after upgrading. Headless and SDK starting modes.

What changed since August: October 20, 2026

Since October 16, 2026, version 2.1.302 makes the no-mode headless and SDK default explicit on third-party providers, with telemetry off, and on fresh installs: Manual, not auto. Passing --permission-mode auto retains auto when the session supports it. Verified against Anthropic's raw changelog and permission docs on October 20, 2026; release dates below come from npm's publish timestamps.

• September 25, 2026 · 2.1.283: Interactive sessions on third-party providers or with telemetry off now start in auto when no permission mode is configured; permissions.defaultMode still takes precedence. Changelog.
• October 2, 2026 · 2.1.288: The client-side classifier ignores an ANTHROPIC_DEFAULT_SONNET_MODEL pin naming Sonnet 5.5 or Opus 5.5 and uses Sonnet 5 instead. Changelog.
• October 2, 2026 · 2.1.288: A conversation too long for the client-side classifier is now compacted instead of causing a permission prompt or failure on every tool call. Changelog.
• October 7, 2026 · 2.1.293: Reverted the 2.1.281 denial-message change that told Claude a denial applied to the outcome, not just the exact command. Changelog.
• October 9, 2026 · 2.1.296: A tool call withheld because its check had no usable answer now appears as a dim Not run row instead of a red error. Changelog.
• October 14, 2026 · 2.1.299: Fixed SDK and headless sessions remaining in auto after the host switched to a model that does not support it. Changelog.
• October 16, 2026 · 2.1.302: Corrected the no-mode headless and SDK starting behavior above and added CLAUDE_CODE_AUTO_MODE_MODEL for the client-side classifier. Conversations too long for server-side checks are now compacted instead of having every checked call denied. Changelog.
• October 19, 2026 · 2.1.304: Made /auto-mode-setup available on Bedrock, Vertex, Foundry, the Claude apps gateway, and telemetry-disabled sessions. Changelog.

The denial-message reversal is not evidence that a permission rule disappeared. Likewise, Not run means the action did not run, not that it passed the check. Press Ctrl+O to read the underlying message in the transcript viewer. Error reference.

How one action moves through auto mode

The decision starts with your rules, then uses automatic approval or classifier review as appropriate:

1. Permission rules apply first. Allow, ask, and deny rules resolve actions, subject to documented exceptions. Broad allow rules that grant arbitrary code execution are suspended in auto mode; a narrow rule such as Bash(npm test) can remain effective.
2. Ordinary reads and local edits usually proceed. Read-only operations and edits in the working directory generally skip the classifier. Protected files, symlinks that lead outside the directory, and network paths have additional checks or prompts. The first read outside the working directories prompts in interactive sessions; that prompt does not appear in headless or background runs.
3. Other actions generally reach the classifier. Shell commands, network operations, and delegated work can need review. Some operations require direct consent instead. In sessions using server-side review, even read-only and sandboxed shell commands wait for that review.

This is a simplified flow, not an assurance that every read or repository edit is automatically allowed. Anthropic documents the full decision order.

What does the classifier see?

For requests sent by the client, the classifier receives your messages, tool calls other than read-only lookups, and your CLAUDE.md instructions. Raw tool results are stripped from those requests. A separate server-side probe checks incoming tool results for suspicious content before Claude reads them. That separation helps prevent a hostile file or webpage from directly instructing both the coding model and its reviewer. Classifier inputs.

Delegation does not avoid review. The classifier checks a subagent's task before it starts, applies the action rules while it works, and reviews its work and final report before the parent receives that report. It also reviews messages sent between agents.

The classifier normally uses Sonnet 5 independently of your /model selection. Server configuration, session-model restrictions, and model availability can change that selection. The October pin fix specifically concerns the client-side classifier; selecting Sonnet 5.5 for coding does not mean Sonnet 5.5 performs every permission check. Default classifier model.

From version 2.1.302, CLAUDE_CODE_AUTO_MODE_MODEL selects the client-side classifier model only. Use a full model ID your provider serves, including its provider-specific ID where needed. For example, merge Anthropic's documented Sonnet 4.6 selection into ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_AUTO_MODE_MODEL": "claude-sonnet-4-6"
  }
}

This does not select the coding model or the server-side reviewer. An Anthropic-configured classifier takes precedence; Opus 5, Sonnet 5.5, Opus 5.5, and models excluded by organization policy fall back to the default classifier selection. If the provider cannot serve your chosen model, checks fail and the checked actions are denied. Confirm the client model through classifier_request_started in a debug log, and check /status for Auto mode server. Classifier selection and verification.

Claude Code can also receive server-side verdicts within the session's model requests. If server review is unavailable for the session, it can fall back to client-side requests. A server check that gives no verdict for an individual action does not authorize that action. For the billing consequences of these paths, see Claude Code auto mode classifier charges.

How to turn auto mode on and off

Start a terminal session explicitly in auto mode:

claude --permission-mode auto

For CI or a script, opt in on the non-interactive invocation:

claude -p "Run the test suite and fix any failures" --permission-mode auto

In the Agent SDK, set permissionMode: "auto" in TypeScript or permission_mode="auto" in Python's ClaudeAgentOptions. Use default when you want Manual behavior, with explicit approval mechanisms for the calls the job needs. For terminal startup, the CLI flag takes precedence over permissions.defaultMode, which takes precedence over the built-in default. An explicit auto request still requires a supported model and permission from organization policy. Startup rules and SDK examples.

During a terminal session, use Shift+Tab to change modes. From Auto, the first press selects Manual. Supported apps have a mode selector. To start a new terminal session in Manual, use:

claude --permission-mode default

For a personal terminal default, merge this into ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "auto"
  }
}

Change "auto" to "default" to start future sessions in Manual while leaving auto selectable. Project-local .claude/settings.json and .claude/settings.local.json cannot enable auto through defaultMode. In VS Code, leave claudeCode.initialPermissionMode unset and select Auto from the mode indicator to remember that choice; that extension setting does not accept auto. Mode controls and starting defaults.

To remove auto mode as an option, use disableAutoMode, whose value is the string "disable", not a Boolean:

{
  "permissions": {
    "disableAutoMode": "disable"
  }
}

This also works as a top-level disableAutoMode setting. An administrator should put it in managed settings to prevent developer overrides. It removes auto from the cycle and makes sessions requesting auto start in Manual. A running auto session leaves the mode when an admin-deployed disabling policy reaches it. Settings reference.

What the safety checks cover, and their limits

The classifier is designed to challenge actions with consequences beyond ordinary repository work. Default blocks include production deployments and migrations, mass cloud deletion, force pushes, permission changes, sensitive-data transfers, and irreversible destruction of files that existed before the session. It initially trusts the working directory and its configured remotes; a remote added or repointed during the session is not automatically trusted. Default classifier rules.

A useful distinction for team leads: routine pushes to the current repository can be permitted, including to its default branch, subject to content checks, permission rules, branch protections, and exceptions for deployment or publication targets. Auto mode is not inherently a human checkpoint before every push. Keep remote branch protections and add explicit approval rules where your workflow requires that checkpoint.

In an interactive session, 3 consecutive classifier blocks or 20 total blocks pause auto mode and restore permission prompts. Approving the prompted action resumes auto mode. A non-interactive run without a permission-prompt tool cannot ask a person: the action stays blocked and Claude continues working. These are fallback thresholds, not safety scores. Fallback behavior.

The long-conversation fix makes continued work more practical, but compaction also matters for policy. The classifier reads conversational boundaries from the transcript, and a boundary can disappear if compaction removes the message containing it. For a lasting prohibition, use an explicit deny rule instead of relying only on an earlier instruction such as “do not deploy.” Conversation boundaries.

Who profits most: seven practical uses

The biggest winners are teams with repetitive, repository-scoped work and tests that can tell Claude when it is wrong. Auto mode reduces time spent on routine approvals. Tests, code review, and a narrow task supply the control.

1. Product teams maintaining large page fleets

A merchandising team responsible for hundreds of localized pages could give Claude a defined component change, let it update the relevant files, run visual and unit checks, fix failures, and prepare a pull request. The payoff is not skipping review. It is receiving one finished change set instead of babysitting every file edit and command.

2. Platform teams running code migrations

A platform engineer moving a monorepo from a deprecated library could ask Claude to find each use, apply the documented replacement, run the affected test suites, and group failures by cause. The work is repetitive, easy to diff, and expensive to interrupt. Auto mode can keep the migration moving while the engineer reviews the final patch and the exceptions.

3. QA teams repairing failed test suites

A QA lead could feed a failed CI run into a tightly scoped branch and ask Claude to reproduce each failure, identify whether code or test expectations changed, patch the likely cause, and rerun only the relevant checks. The payoff is a smaller queue of diagnosed failures, not blind trust in every fix.

4. Product squads turning settled specs into pull requests

Once a feature has a clear acceptance test, a squad could let Claude trace the affected code, implement the change, add tests, and write a pull-request summary. Humans still decide whether the behavior matches the product intent. Auto mode can reduce the approval clicks between those steps.

5. Machine-learning teams running overnight experiment loops

An ML team could queue a bounded evaluation task at the end of the day, let Claude change experiment code, run approved evaluations, compare metrics, and return candidate pull requests by morning. The environment has to be explicit. Shared clusters, production data, and broad deletion rights should stay outside the trust boundary unless an administrator deliberately configures them.

6. Internal-tools teams clearing maintenance queues

An internal-tools group could turn low-risk issues such as dependency updates, form validation fixes, and small dashboard changes into isolated branches. Claude can edit, test, and document each change while a human owns prioritization and merge approval. This is where uninterrupted execution converts a long tail of ignored chores into reviewable work.

7. Solo founders prototyping inside one repository

A founder with a clear feature sketch could let Claude build the first pass, run the local app, fix obvious errors, and leave a concise change summary. The payoff is a coherent prototype session without dozens of prompts. The catch is equally clear: weak tests and vague product intent still produce polished-looking mistakes.

For the broader mechanics behind projects, context, and review, see How to Use Claude Code. If you are choosing the underlying tool rather than the permission mode, the current AI coding-agent comparison is the better starting point.

What you could build around it

The useful control layer is policy, orchestration, and review evidence. These are implementation ideas for a team adopting auto mode, not measured product opportunities.

1. Auto Mode Rollout Console

A platform team could inventory trusted repositories, domains, cloud buckets, and sensitive data locations, then prepare reviewed autoMode.environment, hard_deny, soft_deny, and allow entries while retaining Anthropic's $defaults. A small first version could produce a settings file and a set of expected allow/block cases for an administrator to review. Configuration guide.

For a guided starting point, run /auto-mode-setup in Claude Code. It drafts environment entries from your project and recent sessions; review the draft before accepting it into ~/.claude/settings.json, then inspect the result with claude auto-mode config. Version 2.1.304 extends availability to Bedrock, Vertex, Foundry, the Claude apps gateway, and telemetry-disabled sessions. Setup workflow, availability change.

The useful output is a clear boundary around the task. A settings generator alone is not proof that every action inside a run is safe.

2. An overnight pull-request desk

A maintenance queue could turn well-specified tickets into isolated branches with test results for a named reviewer. Framework migrations, dependency work, and test repair are plausible starting points because the expected result can be described concretely.

The catch is task quality. Vague tickets produce plausible changes without a reliable acceptance check. Define the test command, execution budget, credentials, and human handoff before scheduling unattended work; do not assume a missing permission prompt means the job completed.

3. An independent evidence gate for agent-written code

A review gate could collect the diff, test output, and acceptance criteria before code reaches a human approver. The point is to verify the resulting behavior, not merely ask another model whether the change looks reasonable.

That separates permission to perform a step from evidence that the resulting code is correct. Auto mode supplies the former decision; your delivery process still owns the latter.

Limits and the honest take

Auto mode reduces interruptions. It does not solve ambiguous goals, weak tests, unsafe infrastructure design, or bad review culture.

Do not use it as the final authority for production migrations, account-wide permission changes, destructive infrastructure work, secret handling, or a merge where failure has a large impact. Keep a person at those boundaries and give the session only the infrastructure access the task needs.

Configuration can also create its own risk. Adding a narrow trusted destination may address a false positive. Replacing hard_deny, soft_deny, allow, or environment without the literal $defaults discards that section's built-in list. Inspect effective policy with claude auto-mode config. The autoMode.classifyAllShell: true setting suspends shell allow rules so shell commands receive classifier review, with critical-path removals still handled separately. Configuration and defaults.

My take: use auto mode for contained software work when you can define success and review the result. Start with a maintenance task in an isolated branch, make the push or deploy checkpoint explicit, and inspect both the patch and test evidence before expanding the rollout. Keep Manual for work whose consequences you cannot bound in advance.

If you want a controlled agent workflow like this built for your engineering team, AI agent development is the right place to start.