Auto Mode Becomes the Claude Code Default on 14 August

From 14 August 2026, auto mode is the default permission mode for new Claude Code sessions on Pro, Max and Team plans. If Claude suddenly stops asking before it runs commands, nothing is broken. The default changed underneath you.

Exactly what changes

Situation	What happens on 14 August
You never set a default mode	New sessions start in auto mode instead of Manual
You set a default yourself	Your setting stays. You get a one-time prompt offering the switch, which you can decline
Your organisation manages the default	Nothing changes
You are on Enterprise	Not included in this change

Existing sessions are not converted mid-flight, and you can still switch modes at any time with Shift+Tab or the mode selector. This changes the starting point, not your control over it.

One change already in effect on those plans, and easy to miss: the classifier calls auto mode makes no longer count toward your usage limits. That removes the main practical argument against leaving it on.

What auto mode actually does

It is not “approve everything”. A separate classifier model reviews each action before it runs and blocks anything that escalates beyond what you asked for, targets infrastructure it does not recognise, or looks driven by content Claude just read rather than by you.

Blocked by default, among a long list: curl | bash, production deploys and migrations, force push, git reset --hard, terraform destroy, mass deletion on cloud storage, printing a live credential into the transcript, and opening a tunnel that exposes a local service to the internet.

Allowed by default: local file operations in your working directory, installing dependencies your lock files already declare, read-only HTTP requests, and pushing to branches of the repository you are working in.

Keeping Manual, or choosing something else

The mode that reviews every action is labelled Manual but its config value is default. From v2.1.200 the CLI also accepts manual as an alias, so either works:

{
  "permissions": {
    "defaultMode": "manual"
  }
}

Put that in ~/.claude/settings.json for every project. Other values are acceptEdits, plan, auto, dontAsk and bypassPermissions, described in permission modes.

To go the other way and start every session in auto mode now, before the switch:

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

New sessions then show auto mode on in the status bar.

If you administer a team

Administrators can remove auto mode entirely by setting permissions.disableAutoMode to "disable" in managed settings. That takes it out of the Shift+Tab cycle and rejects --permission-mode auto at startup.

Worth deciding deliberately rather than by default. Auto mode reduces prompt fatigue substantially, and the classifier blocks a long list of genuinely destructive actions, but Anthropic is explicit that it reduces prompts rather than guaranteeing safety.

Why this matters more for remote sessions

Permission mode is the single thing that decides whether a session you are not watching finishes or stalls. A Remote Control session, a channel waiting on a CI event, or a background session all stop dead at a permission prompt until someone answers it.

So for anyone driving Claude Code from a phone or leaving work running, this change is an improvement rather than an intrusion. It is the difference between coming back to finished work and coming back to a question from twenty minutes ago.

Two caveats specific to remote work:

• You cannot select auto mode from the phone for a Remote Control session. The app offers Manual, Accept edits and Plan only. Set it on the host before you leave.
• Auto mode still pauses eventually. If the classifier blocks three actions in a row, or twenty in a session, it stops and reverts to prompting. Those thresholds are not configurable, so auto mode lowers the odds of a stall without eliminating them.

What to do today

1. Decide whether you want auto mode. For most people driving sessions remotely, yes.
2. If you want to keep Manual, set defaultMode in ~/.claude/settings.json before the 14th, or decline the one-time prompt when it appears.
3. If you administer a team, decide whether disableAutoMode belongs in your managed settings rather than discovering the change through a support ticket.
4. Either way, read what the classifier blocks and allows once, so the first block does not look like a bug.