Claude Code auto mode: the new default

What auto mode changes on 14 August 2026

Claude Code auto mode runs tool calls without stopping to ask you, and sends each action to a separate classifier model for review first. From 14 August 2026 it is the mode new sessions start in on Pro, Max, and Team plans. You can switch modes at any time, and a default you already set for yourself is not overwritten.

The documentation states the change like this:

Starting August 14, 2026, auto mode becomes the default permission mode for new sessions on Pro, Max, and Team plans. You can switch modes at any time. A default you set yourself stays in place unless you accept the one-time switch prompt, and a default your organization manages is unchanged.

Two clauses there matter more than the date. A defaultMode you set in your own settings file survives the change. A default your organization deploys through managed settings survives it too. The announcement post adds that auto mode stays optional for Enterprise plans and for accounts using the API during the first part of the rollout.

If you run Claude Code on a VPS (virtual private server), the change is worth reading before it lands. A permission prompt is a checkpoint that needs a person at the keyboard. On a remote box you are often not there, so the mode a session starts in is the mode it stays in for hours.

The Claude Code permission modes, from most oversight to least

There are six modes. The name at the start of each line is the value you write in settings or pass to --permission-mode.

• default: Claude asks before each new tool use. Reads inside your working directory still run without a prompt. The CLI (command line interface) labels this mode Manual and accepts manual as an alias from Claude Code v2.1.200.
• plan: Claude reads files and runs commands to explore, and does not edit your source. Edits stay blocked until you approve the plan.
• acceptEdits: file edits run without a prompt, along with the filesystem commands mkdir, touch, rm, rmdir, mv, cp and sed. This applies only to paths inside your working directory or your additionalDirectories. Every other shell command still prompts.
• auto: everything runs, with the classifier checking each action first. Explicit ask rules still force a prompt.
• dontAsk: Claude Code auto-denies anything that would have prompted you. Only your allow rules, the built-in read-only Bash commands, and calls a PreToolUse hook approves will run. The session never waits for input.
• bypassPermissions: prompts and safety checks are skipped, including writes to protected paths such as .git and .claude.

Press Shift+Tab during a session to cycle default to acceptEdits to plan. The status bar shows where you landed, such as ⏵⏵ auto mode on or a gray ⏸ manual mode on. The other modes are not in that cycle by default. auto joins it once your account meets the requirements for it. bypassPermissions joins it only when the session was started with --permission-mode bypassPermissions or --dangerously-skip-permissions. dontAsk never appears there, so set it with claude --permission-mode dontAsk.

Auto mode also needs a recent model, which is the usual reason it does not appear at all. As of August 2026 the documentation lists Claude Opus 4.6 or later, Sonnet 4.6 or later, and Fable 5 on the Anthropic API, and says older models such as Sonnet 4.5 are not supported on any provider. If Claude Code reports auto mode as unavailable, one of those requirements is unmet. It is not a temporary outage, so waiting will not fix it.

Two controls hold in every mode, including bypassPermissions: deny rules and explicit ask rules. Those are the levers you keep whichever mode a session starts in.

What the auto mode classifier blocks

The classifier is a second model that reads the pending action and decides whether it fits what you asked for. The documentation describes its job in one sentence:

A separate classifier model reviews actions before they run, blocking anything that escalates beyond your request, targets unrecognized infrastructure, or appears driven by hostile content Claude read.

Blocked by default, in the categories a server operator meets most often:

• Downloading and executing code, such as curl | bash
• Production deploys and migrations
• Force push
• Modifying shared infrastructure
• Opening a tunnel or reverse shell that makes a local service reachable from the public internet
• Printing a live credential or token into the transcript or a file

Allowed by default:

• Local file operations in your working directory
• Installing dependencies declared in your lock files or manifests
• Read-only HTTP requests
• Pushing to any branch of the repository you are working in

Do not work from a summary like the one above. Run claude auto-mode defaults to print the full rule lists as JSON, and read the set that shipped with the version you have installed.

Two documented limits matter before you lean on this. First, the classifier sees your messages, the tool calls, and your CLAUDE.md content, and tool results are stripped out, so text inside a file or a web page Claude read cannot address the classifier directly. Second, when the classifier blocks an action 3 times in a row or 20 times in one session, auto mode pauses and Claude Code goes back to prompting you. Those thresholds are not configurable. In non-interactive mode with the -p flag there is nobody to prompt, so repeated blocks abort the session instead.

That second behaviour is the one that bites on a remote box. An unattended run that trips the limit stops and waits for a person who is not looking at the terminal.

Where the modes live in settings.json

Everything above is one object in a settings file.

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [
      "Bash(npm run test *)",
      "Bash(git status)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(docker compose up *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

Rules are evaluated in order: deny, then ask, then allow. The first match in that order decides the outcome, and a narrower rule does not beat a broader one that comes earlier. A deny rule for Bash(aws *) blocks aws s3 ls even when you also allowed that exact command, so a deny rule cannot carry exceptions.

ask is the rule type that earns its keep in auto mode. Auto mode removes the routine prompt, and an ask rule puts one back for the specific command you want a person on. Your deploy command belongs there. So does Bash(git push *) if you want a checkpoint before code leaves the box. Keeping credential files in deny is the other half of that, and it pairs with keeping credentials out of an agent's reach in the first place.

The settings files themselves, lowest precedence first:

• ~/.claude/settings.json: your user settings, applied in every project.
• .claude/settings.json: project settings, committed to the repository.
• .claude/settings.local.json: your own settings for one repository, git-ignored.
• Managed settings, deployed by an administrator. On Linux that file is /etc/claude-code/managed-settings.json. Nothing overrides a managed permission rule, including a command line flag.

One trap here has a documented cause. defaultMode: "auto" is ignored when it comes from .claude/settings.json or .claude/settings.local.json, from Claude Code v2.1.142 onwards, so that a repository cannot grant itself auto mode by shipping a settings file. Set it there and the session starts in default mode with no error printed anywhere. Move the line to ~/.claude/settings.json. Run /permissions to list every active rule next to the file it came from.

The two switches that turn a mode off

Administrators get two kill switches, and both take the string "disable" rather than a boolean.

{
  "permissions": {
    "disableAutoMode": "disable",
    "disableBypassPermissionsMode": "disable"
  }
}

The documentation is precise about where to put them:

To prevent bypassPermissions or auto mode from being used, set permissions.disableBypassPermissionsMode or permissions.disableAutoMode to "disable" in any settings file. These are most useful in managed settings where they can't be overridden.

disableAutoMode removes auto from the Shift+Tab cycle and rejects --permission-mode auto at startup. disableBypassPermissionsMode does the same job for bypass mode, and it works from any scope, so you can set it in your own ~/.claude/settings.json to lock yourself out of a mode you would rather not reach for at 2am on a live server. On a box other people use, put both in /etc/claude-code/managed-settings.json instead, because a user settings file belongs to the user and a managed one does not.

Why auto mode on a VPS needs an isolation boundary

The classifier reviews one action at a time. It does not contain what an approved action then does. The documentation draws the line plainly:

The classifier is a per-action control, not an isolation boundary, so an isolation boundary still adds defense in depth for unattended runs, and is not required the way it is for --dangerously-skip-permissions.

So the pairing for a remote box is auto mode plus an environment you are willing to lose, not bypassPermissions plus hope. Bypass mode is documented for isolated environments only: containers, virtual machines, or dev containers without internet access, where Claude Code cannot damage your host system. A VPS running your database and your reverse proxy is none of those.

Three things carry most of the weight on a server. Run Claude Code as a normal user, never root. Give that user a working directory and nothing else worth reading. Rebuild the box rather than repair it, which is the argument for a disposable VM you throw away after each job. The hardening detail behind those, from user creation to firewall rules, is covered in the full safety pass for running Claude Code on a VPS, so it is not repeated here.

Claude Code enforces the root rule itself. On Linux and macOS it refuses to start in bypass mode under sudo or as root:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

That check is skipped inside a recognized sandbox, which is why the documented answer for autonomous container work is a dev container that runs Claude Code as a non-root user. If you drive the agent from a phone or a laptop over SSH, the same reasoning applies to a long-running Claude Code session held open in tmux: nobody is watching the prompt while the session runs.

Set up the Bash sandbox on an Ubuntu VPS

The built-in sandbox restricts the filesystem and network access of every Bash command Claude runs, and the operating system enforces that on child processes too. On Linux it needs two packages.

sudo apt-get install bubblewrap socat

Start Claude Code and run /sandbox. The panel opens with a Mode tab and an Overrides tab, plus a Dependencies tab listing whatever is missing. The dependency check runs at startup, so restart Claude Code after installing the packages or the panel will still report them as absent.

On Ubuntu 24.04 and later, the default AppArmor policy stops bubblewrap from creating the user namespaces it needs, so the sandbox fails to start. Check whether that applies to your box:

sysctl kernel.apparmor_restrict_unprivileged_userns

A 0, or an error saying the key does not exist, means there is nothing to do. A 1 means bwrap needs its own profile:

sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF
sudo systemctl reload apparmor

The profile applies to bwrap itself, not to the commands it runs inside the sandbox. Then narrow the boundary in settings:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

That block belongs in the project's .claude/settings.json, because . resolves to the project root only from project settings. Put the same lines in ~/.claude/settings.json and . resolves to ~/.claude instead, so the denyRead rule keeps your project files blocked and every command fails to read the code it is meant to edit.

Know what this does not cover. The sandbox constrains Bash and its child processes. The built-in file tools run inside the Claude Code process, and MCP (model context protocol) servers and hooks are separate processes that run unconstrained on the host. To put all of them behind one boundary, run the whole Claude Code process inside a container, a virtual machine, or the @anthropic-ai/sandbox-runtime package, which is a beta research preview at the time of writing.

Which mode does each setup deserve?

A solo repo on your own laptop

Use auto, with ask rules on the actions you want to see go past. You are at the keyboard, the classifier fallback can actually reach you, and the damage is bounded by one machine you control. This is the case the 14 August default was written for.

A shared VPS

Use auto per user, set in each user's own ~/.claude/settings.json, on a box where the account running Claude Code is not root and cannot read the other users' work. Deploy disableBypassPermissionsMode as "disable" in /etc/claude-code/managed-settings.json, together with the deny rules that protect shared paths. A shared box is the clearest case where bypassPermissions is wrong, because the isolation boundary that mode assumes does not exist: the other tenants are inside it.

CI and unattended sessions

Use dontAsk with an explicit allow list of the commands the job needs. Auto-deny is the correct failure mode when no person will ever see a prompt. Auto mode runs non-interactively too, but repeated classifier blocks abort a -p session, so a job that hits them fails partway through with work half done. Keep bypassPermissions for a container or virtual machine you rebuild from an image, and off any host that also runs something you care about.

FAQ

When does auto mode become the default in Claude Code?

From 14 August 2026, for new sessions on Pro, Max, and Team plans. The documentation adds that you can switch modes at any time, that a default you set yourself stays in place unless you accept the one-time switch prompt, and that a default your organization manages is unchanged. The announcement notes auto mode stays optional for Enterprise plans and for accounts using the API during the first part of the rollout. Check what a session is actually in by looking at the status bar, which reads ⏵⏵ auto mode on in auto mode.

Should I use auto mode or bypassPermissions on a VPS?

Auto mode, paired with an isolation boundary. The classifier reviews each action before it runs, but the documentation is explicit that it is a per-action control and not an isolation boundary, so an unattended run still wants a container, a virtual machine, or a box you are willing to rebuild. bypassPermissions skips the checks entirely and is documented for isolated environments only. Claude Code refuses to start in that mode as root on Linux and prints --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons.

How do I stop anyone on my server from using auto mode or bypass mode?

Set permissions.disableAutoMode and permissions.disableBypassPermissionsMode to the string "disable" in /etc/claude-code/managed-settings.json. Managed settings sit above every other scope, so no user settings file and no command line flag can override them. disableAutoMode removes auto from the Shift+Tab cycle and rejects --permission-mode auto at startup. disableBypassPermissionsMode also works from any scope, so a single user can set it in their own ~/.claude/settings.json.

Why is my defaultMode: "auto" setting ignored?

Because it is in the wrong file. From Claude Code v2.1.142, defaultMode: "auto" is ignored when it comes from .claude/settings.json or .claude/settings.local.json, so that a repository cannot grant itself auto mode by shipping a settings file. The session starts in default mode and prints no error. Move the setting to ~/.claude/settings.json, then run /permissions to confirm which file each active rule came from. If auto mode is still unavailable, check the model requirement: older models such as Sonnet 4.5 are not supported on any provider.