Claude Code auto mode: wetin go change for you

Wetin auto mode go change on 14 August 2026

Claude Code auto mode dey run tool calls without stopping to ask you, and e dey send each action go separate classifier model make e review am first. From 14 August 2026, na the mode new sessions go start with for Pro, Max, and Team plans. You fit switch mode anytime, and default wey you don already set for yourself no go change.

The documentation talk the change like this:

From 14 August 2026, auto mode go become the default permission mode for new sessions for Pro, Max, and Team plans. You fit switch mode anytime. Default wey you set yourself go remain unless you accept the one-time switch prompt, and default wey your organization manage no go change.

Two clauses for there matter pass the date. defaultMode wey you set for your own settings file go remain after the change. Default wey your organization deploy through managed settings go remain too. The announcement post add say auto mode go remain optional for Enterprise plans and accounts wey dey use the API during the first part of the rollout.

If you dey run Claude Code for VPS (virtual private server), e good make you read about this change before e take effect. Permission prompt na checkpoint wey person for keyboard need handle. For remote box, most times you no dey there, so mode wey session start with na the mode e go remain with for hours.

Claude Code permission modes, from the one wey get most oversight reach the one wey get least

Six modes dey. The name for start of each line na the value wey you write for settings or pass to --permission-mode.

• default: Claude go ask before e use any new tool. Reads inside your working directory still go run without prompt. The CLI (command line interface) dey call this mode Manual and e accept manual as alias from Claude Code v2.1.200.
• plan: Claude go read files and run commands to explore, but e no go edit your source. Edits go remain blocked until you approve the plan.
• acceptEdits: file edits go run without prompt, together with filesystem commands mkdir, touch, rm, rmdir, mv, cp and sed. This one apply only to paths inside your working directory or your additionalDirectories. Every other shell command still go ask for prompt.
• auto: everything go run, while the classifier dey check each action first. Explicit ask rules still go force prompt.
• dontAsk: Claude Code go auto-deny anything wey suppose ask you for prompt. Na only your allow rules, the built-in read-only Bash commands, and calls wey a PreToolUse hook approves go run. The session no go ever wait for input.
• bypassPermissions: prompts and safety checks go skip, including writes to protected paths such as .git and .claude.

Press Shift+Tab during a session to cycle from default to acceptEdits to plan. The status bar go show where you land, such as ⏵⏵ auto mode on or gray ⏸ manual mode on. The other modes no dey inside that cycle by default. auto go join am once your account meet the requirements. bypassPermissions go join am only when you start the session with --permission-mode bypassPermissions or --dangerously-skip-permissions. dontAsk no go ever appear there, so set am with claude --permission-mode dontAsk.

Auto mode still need recent model, and na this one usually make e no appear at all. As of August 2026, the documentation list Claude Opus 4.6 or later, Sonnet 4.6 or later, and Fable 5 for the Anthropic API. E also talk say older models like Sonnet 4.5 no dey supported for any provider. If Claude Code report say auto mode no dey available, one of those requirements no dey met. No be temporary outage, so waiting no go fix am.

Two controls dey hold for every mode, including bypassPermissions: deny rules and explicit ask rules. Na those levers you still get, whichever mode the session start with.

Wetín auto mode classifier dey block

Classifier na second model wey dey read the pending action and decide whether e match wetin you ask for. Documentation describe the work for one sentence:

One separate classifier model dey review actions before dem run, and e dey block anything wey pass wetin you request, target infrastructure wey e no recognize, or look like say hostile content wey Claude read dey cause am.

By default, e dey block these ones wey server operator dey meet often:

• Downloading and executing code, like curl | bash
• Production deploys and migrations
• Force push
• Modifying shared infrastructure
• Opening tunnel or reverse shell wey make local service reachable from public internet
• Printing live credential or token inside transcript or file

By default, e dey allow these ones:

• Local file operations inside your working directory
• Installing dependencies wey your lock files or manifests declare
• Read-only HTTP requests
• Pushing to any branch for the repository wey you dey work on

No use summary like the one above dey work. Run claude auto-mode defaults to print the complete rule lists as JSON, then read the set wey come with the version wey you install.

Two documented limits matter before you depend on this. First, classifier dey see your messages, the tool calls, and your CLAUDE.md content, but tool results dey removed. So text inside file or web page wey Claude read no fit address the classifier directly. Second, when classifier block action 3 times one after another or 20 times for one session, auto mode pauses and Claude Code go return to prompting you. You no fit configure these thresholds. For non-interactive mode with -p flag, nobody dey available to answer prompt, so repeated blocks go abort the session instead.

Na this second behaviour dey cause problem for remote box. Unattended run wey reach the limit go stop and wait for person wey no dey look the terminal. The other part of the fix na to narrow wetin agent suppose do, and skill wey dey push agent toward the smallest change wey work dey help session avoid entering the broad actions wey classifier dey stop.

Where the modes dey for settings.json

Everything wey dey above na one object for 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 dey evaluate in order: deny, then ask, then allow. The first match for that order go decide the outcome, and narrower rule no fit override broader rule wey come earlier. Deny rule for Bash(aws *) go block aws s3 ls even when you also allow that exact command, so deny rule no fit get exceptions.

ask na the rule type wey useful for auto mode. Auto mode remove the routine prompt, and ask rule put am back for the specific command wey you want person to approve. Your deploy command belong there. Bash(git push *) too, if you want checkpoint before code comot from the machine. Keeping credential files for deny na the other part of this, and e work together with keeping credentials away from agent reach from the beginning.

The settings files themselves, from lowest precedence to highest:

• ~/.claude/settings.json: your user settings, wey apply for every project.
• .claude/settings.json: project settings, wey you commit to the repository.
• .claude/settings.local.json: your personal settings for one repository, wey git ignore.
• Managed settings, wey administrator deploy. For Linux, that file na /etc/claude-code/managed-settings.json. Nothing fit override managed permission rule, including command line flag.

One trap here get documented cause. defaultMode: "auto" dey ignored when e come from .claude/settings.json or .claude/settings.local.json, from Claude Code v2.1.142 onward, so repository no fit grant itself auto mode by shipping settings file. If you set am there, session go start for default mode without printing any error anywhere. Move the line go ~/.claude/settings.json. Run /permissions to list every active rule beside the file wey e come from.

Switch wey fit turn mode off

Administrators get two kill switches, and both dey take string "disable" instead of boolean.

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

The documentation talk exactly where to put dem:

To stop bypassPermissions or auto mode from being used, set permissions.disableBypassPermissionsMode or permissions.disableAutoMode to "disable" for any settings file. Dem dey most useful for managed settings wey users no fit override.

disableAutoMode removes auto from Shift+Tab cycle and rejects --permission-mode auto when startup happen. disableBypassPermissionsMode do the same thing for bypass mode, and e work from any scope. So you fit set am for your own ~/.claude/settings.json to lock yourself out of mode wey you no want reach at 2am for live server. For server wey other people dey use, put both for /etc/claude-code/managed-settings.json instead, because user settings file belong to the user, but managed settings file no belong to the user.

Why auto mode for VPS need isolation boundary

The classifier dey review one action at a time. E no dey contain wetin approved action go do after. The documentation make the boundary clear:

The classifier na per-action control, e no be isolation boundary, so isolation boundary still add defense in depth for unattended runs, and e no required the way e be for --dangerously-skip-permissions.

So the correct pairing for remote box na auto mode plus environment wey you ready to lose, no be bypassPermissions plus hope. Documentation only support bypass mode for isolated environments: containers, virtual machines, or dev containers wey no get internet access, where Claude Code no fit damage your host system. VPS wey dey run your database and reverse proxy no be any of these.

Three things dey carry most of the protection for server. Run Claude Code as normal user, never root. Give that user one working directory and nothing else worth reading. Rebuild the box instead of repairing am. Na this be the reason for disposable VM wey you go throw away after each job. The hardening details behind these steps, from user creation to firewall rules, dey covered for the full safety pass for running Claude Code on a VPS, so we no repeat dem here.

Claude Code enforce the root rule by itself. For Linux and macOS, e refuse 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 no dey run inside recognized sandbox. Na why the documented answer for autonomous container work na dev container wey run Claude Code as non-root user. If you dey control the agent from phone or laptop over SSH, the same reasoning apply to long-running Claude Code session wey you keep open inside tmux: nobody dey watch the prompt while the session dey run.

Set up the Bash sandbox for one Ubuntu VPS

The built-in sandbox dey restrict filesystem and network access for every Bash command wey Claude run, and operating system dey enforce the same restriction for child processes too. For Linux, e need two packages.

sudo apt-get install bubblewrap socat

Start Claude Code and run /sandbox. Panel go open with Mode tab and Overrides tab, plus Dependencies tab wey list anything wey still missing. Dependency check dey run when startup happen, so restart Claude Code after you install the packages. Otherwise panel go still report say dem no dey present.

For Ubuntu 24.04 and later, default AppArmor policy dey stop bubblewrap from creating the user namespaces wey e need, so sandbox no go start. Check whether this one affect your box:

sysctl kernel.apparmor_restrict_unprivileged_userns

A 0, or error wey talk say the key no dey exist, mean say nothing remain to do. A 1 mean say bwrap need im 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 apply to bwrap itself, no be to the commands wey e run inside sandbox. Then narrow the boundary for settings:

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

That block belong inside the project's .claude/settings.json, because . dey resolve to project root only from project settings. If you put the same lines inside ~/.claude/settings.json, . go resolve to ~/.claude instead. So the denyRead rule go keep your project files blocked, and every command go fail to read the code wey e suppose edit.

Know wetin this no cover. Sandbox dey constrain Bash and im child processes. Built-in file tools dey run inside Claude Code process, while MCP (model context protocol) servers and hooks na separate processes wey dey run without constraint for the host. To put all of dem behind one boundary, run the complete Claude Code process inside container, virtual machine, or the @anthropic-ai/sandbox-runtime package. As at the time of writing, that package na beta research preview.

Wetin mode each setup suppose use?

One repo for your own laptop

Use auto, with ask rules for the actions wey you want to allow. You dey for the keyboard, classifier fallback fit actually reach you, and the damage dey limited to one machine wey you control. Na this case the 14 August default target.

Shared VPS

Use auto for each user, set am for each user own ~/.claude/settings.json, for a box wey the account wey dey run Claude Code no be root and no fit read other users' work. Deploy disableBypassPermissionsMode as "disable" for /etc/claude-code/managed-settings.json, together with deny rules wey protect shared paths. Shared box na the clearest case wey bypassPermissions wrong, because the isolation boundary wey that mode assume no dey exist: the other tenants dey inside am.

CI and unattended sessions

Use dontAsk with explicit allow list of the commands wey the job need. Auto-deny na the correct failure mode when nobody go ever see prompt. Auto mode dey run non-interactively too, but repeated classifier blocks dey abort -p session, so job wey hit dem go fail halfway with work wey remain half done. Keep bypassPermissions for container or virtual machine wey you rebuild from image, and no use am for any host wey dey run something wey matter to you.

FAQ

Auto mode go become default for Claude Code when?

From 14 August 2026, e go apply to new sessions for Pro, Max, and Team plans. The documentation talk say you fit change mode anytime. Any default wey you set by yourself go remain unless you accept the one-time switch prompt. Default wey your organization manage no go change. The announcement talk say auto mode go remain optional for Enterprise plans and accounts wey dey use the API during the first part of the rollout. Check the mode wey the session dey use by looking the status bar, wey go show ⏵⏵ auto mode on for auto mode.

I suppose use auto mode or bypassPermissions for VPS?

Use auto mode together with isolation boundary. The classifier dey review every action before e run, but the documentation clear say na per-action control e be, not isolation boundary. So unattended run still need container, virtual machine, or machine wey you fit rebuild. bypassPermissions dey skip all the checks, and the documentation say make you use am only for isolated environments. Claude Code no go start for that mode as root on Linux, and e go print --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons.

How I fit stop anybody for my server from using auto mode or bypass mode?

Set permissions.disableAutoMode and permissions.disableBypassPermissionsMode to string "disable" inside /etc/claude-code/managed-settings.json. Managed settings dey above every other scope, so no user settings file or command line flag fit override dem. disableAutoMode dey remove auto from the Shift+Tab cycle and reject --permission-mode auto for startup. disableBypassPermissionsMode still dey work from any scope, so one user fit set am inside their own ~/.claude/settings.json.

Why my defaultMode: "auto" setting no dey work?

Because e dey inside wrong file. From Claude Code v2.1.142, defaultMode: "auto" dey ignored when e come from .claude/settings.json or .claude/settings.local.json. This one stop repository from granting itself auto mode by shipping settings file. The session go start for default mode and e no go print error. Move the setting go ~/.claude/settings.json, then run /permissions to confirm which file each active rule come from. If auto mode still no dey available, check the model requirement: older models like Sonnet 4.5 no dey supported for any provider.