Claude Code's Auto Mode Is Now the Default: What Changed

What's changing on 14 August 2026

Starting 14 August 2026, auto mode becomes the default permission mode for new Claude Code sessions on Pro, Max and Team plans. Instead of pausing to ask before every file edit, shell command or network request, a session in auto mode runs continuously, with a separate classifier model checking each action before it executes rather than a human being asked first.

This is a default change, not a removal of choice. If you've already set your own default mode, in ~/.claude/settings.json or through the mode selector, it stays exactly as it is: you get a one-time prompt offering the switch, and declining it leaves your setting untouched. A default your organisation manages through managed settings doesn't change either way. You can still cycle modes at any point in a session with Shift+Tab.

Anthropic announced the change on the Claude blog and covered it in the Claude Code Week 32 changelog digest, alongside two other features that shipped the same week: cross-session messaging, where a session can pass a note to another one of your open sessions with SendMessage, and self-hosted environments, a public beta on Team and Enterprise that runs cloud sessions on infrastructure you control via claude self-hosted-runner.

What auto mode actually does

Auto mode isn't "skip all checks." That's what bypassPermissions mode already does, and Anthropic's own documentation is explicit that bypass mode "offers no protection against prompt injection or unintended actions." Auto mode is different: a classifier model, Sonnet 5 by default, reviews Claude's intended action against your request and the visible conversation before it runs, and blocks anything that:

• escalates beyond what you asked for
• targets infrastructure the classifier doesn't recognise as yours
• appears to be driven by hostile content Claude picked up from a tool result, file, or web page, rather than from you directly

Explicit permissions.ask rules still force a manual prompt regardless of what the classifier would otherwise allow, so anything you've deliberately gated stays gated.

What gets blocked by default

Anthropic's permission modes documentation lists specific, named cases the classifier blocks without asking first. The most relevant for day-to-day coding work:

• Destructive git operations that would discard uncommitted changes: git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop, git stash clear.
• Recursive forced deletes such as rm -rf "$VAR" when the variable's value never appeared anywhere in the conversation the classifier can see. The block clears once you name the exact path, since the classifier reasons over the transcript, not command output.
• Removals targeting the filesystem root or your home directory, such as rm -rf / or rm -rf ~, including when the removal is buried inside command or process substitution.
• Writes to Claude Code's own session transcripts, the .jsonl files under ~/.claude/projects/, whether attempted directly or through a shell command.
• Pushing secrets, or confidential or personal data, to a repository the classifier believes is public.
• Sending keystrokes into Claude Code's own terminal pane to manipulate its own interface or oversight.

Pushing to any branch of the repository you're actively working in, including the default branch, and opening a pull request that matches your request, both run without a prompt under auto mode. If you want a human checkpoint before either, add a permissions.ask rule rather than relying on the classifier to hold the line for you.

Auto mode also nudges Claude to keep working through a task rather than stopping to ask clarifying questions, though Claude still asks when your prompt or an active skill explicitly depends on an answer.

What happens when the classifier blocks something

Claude Code shows a notification and lists the blocked action under Recently denied in /permissions, where pressing r retries it with manual approval. If the classifier blocks the same action three times in a row, or twenty times total in one session, auto mode pauses and Claude Code falls back to prompting normally until you approve something and it resumes. Those thresholds aren't configurable.

Requirements: who actually gets auto mode

Auto mode isn't universal yet. Per Anthropic's documentation, it requires:

Older models, including Sonnet 4.5, Opus 4.5, Haiku, and Claude 3 models, aren't supported on any provider. On Claude Enterprise, the Claude API, and third-party providers, auto mode remains opt-in for now; Anthropic says it plans to extend the default there within the following month.

How to opt out

If you'd rather keep manual review, set your own default explicitly. In ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "default"
  }
}

"default" is the config value for what the CLI, VS Code and JetBrains extensions, and the desktop app all label Manual mode in their UI, claude --permission-mode manual works as an alias for the same thing from the command line. Setting this in your user settings before 14 August, or accepting the switch prompt and then changing it back, both leave you exactly where you were before the change.

An organisation admin who wants to block auto mode for every developer sets permissions.disableAutoMode to "disable" in managed settings; this removes auto from the Shift+Tab cycle entirely and rejects --permission-mode auto at startup.

Auto mode vs the other permission modes

default (Manual)   → reads only, everything else prompts
acceptEdits        → reads, file edits, and common filesystem commands run without asking
plan                → read-only exploration; classifier reviews commands during planning when auto mode is available
auto                → everything runs, with the classifier checking each action first
bypassPermissions   → nothing is checked; no classifier, no prompts

Auto mode sits between acceptEdits and bypassPermissions in how much it lets through, but it's a different mechanism from either, not just a wider version of acceptEdits. acceptEdits auto-approves a fixed category of actions with no review step. Auto mode reviews every action against the context of your actual request before deciding, which is why Anthropic's own guidance still frames it as a way to reduce prompts rather than eliminate risk. The warning in their docs is direct: "Auto mode reduces permission prompts but does not guarantee safety. Use it for tasks where you trust the general direction, not as a replacement for review on sensitive operations."

What this means if you use skills

Nothing about the SKILL.md format or how skills are discovered changes here. This is entirely a permissions change to the agent running the skill, not to skills themselves. Two things are worth checking in light of it, though:

Skills with a permissionMode in their frontmatter get overridden inside auto mode sessions. Anthropic's documentation is specific that when a subagent runs under auto mode, "any permissionMode in the subagent's frontmatter is ignored," and the classifier applies the same rules it would to the parent session instead. If a skill or subagent you've written relies on forcing a stricter mode for a specific sensitive step, confirm that constraint still holds once a session is running in auto mode, since that per-agent override no longer takes effect there.

Bundled scripts still run. A skill that ships something under scripts/ behaves the same under auto mode as under any other mode: Claude Code executes it if the instructions call for it and the action clears the classifier. Auto mode's added review is a real second check, but it's not a substitute for reading a skill's scripts before installing it. That's still the standing advice in the security guide, and it hasn't gotten less relevant now that fewer actions pause for your explicit approval.

Troubleshooting

Auto mode isn't showing up in the mode cycle. Check the requirements table above first, an unsupported model, provider, or an org-level disableAutoMode setting are the three most common causes, and none of them is a transient outage. If Claude Code instead reports it "cannot determine the safety" of a specific action, that's a separate, per-request classifier failure, usually transient, rather than auto mode being unavailable generally.

You set defaultMode: "auto" and sessions still start in manual mode. As of Claude Code v2.1.142, settings in .claude/settings.json or .claude/settings.local.json are ignored for this specific value, so a repository can't grant itself auto mode through a checked-in settings file. Move the setting to ~/.claude/settings.json instead. In a session the VS Code extension started, a settings-file default doesn't set the starting mode at all; use the extension's own mode indicator.

Routine actions keep getting blocked. This usually means the classifier lacks context about infrastructure you actually trust rather than a bug. Run claude auto-mode defaults to print the full rule set as JSON, and an administrator can add trusted repositories, buckets and services through the autoMode.environment setting described in Anthropic's auto mode configuration docs.

Where to go next

For the underlying skill format this doesn't touch, see What Are Agent Skills? and The SKILL.md Format Explained. If you're deciding how much you trust a skill to run unattended under auto mode, the Agent Skills Security Guide is the relevant companion piece. Browse the current Claude Code catalog at getclaudeskills.com/platforms/claude-code, or everything cataloged at getclaudeskills.com/skills.