# Auto mode is now Claude Code's default: what the classifier approves, and how to switch back

> Source: <https://dev.to/rulestack/auto-mode-is-now-claude-codes-default-what-the-classifier-approves-and-how-to-switch-back-4j2j>
> Published: 2026-08-13 18:17:17+00:00

Starting today — August 14, 2026 — **auto mode is the default permission mode for new Claude Code sessions** on Pro, Max, and Team plans. If you've never touched your permission settings, your next session starts with a one-time switch prompt, and after that Claude runs most actions without asking you first.

That's a real behavior change, not a UI tweak. This post covers what the classifier actually approves, the defaults most people find surprising (pushes to `main`

are allowed), how to keep human checkpoints where you want them, and how to switch back. Everything below is from the official docs as of today.

The [permission modes doc](https://code.claude.com/docs/en/permission-modes) states the change plainly: as of August 14, 2026, new sessions on Pro, Max, and Team plans start in auto mode. You can still switch modes whenever you want, an existing default you set yourself only changes if you accept a one-time switch prompt, and organization-managed defaults don't move at all.

Three details worth pulling out of that:

`defaultMode`

you set yourself survives.`"defaultMode": "plan"`

(or anything else) in your settings, nothing changes unless you accept the switch prompt.Auto mode is not "skip permissions." It routes actions through a **separate classifier model** that reviews each action before it runs. The classifier blocks anything that escalates beyond your request, targets infrastructure it doesn't recognize as yours, or appears driven by hostile content Claude read (prompt injection).

Two rule layers still run **before** the classifier is ever consulted:

`permissions.deny`

rules block outright. Neither the classifier nor your stated intent can override them.`permissions.ask`

rules force a prompt. An explicit ask rule is your stated intent to be asked, so the classifier cannot auto-approve a matching action.So auto mode changes the *default* for unlisted actions, not your explicit rules.

**Pushes and PRs are allowed by default.** Auto mode allows pushes to any branch of the repository you're working in — *including the default branch* — and pull request creation. (Before v2.1.211 the classifier only allowed your working branch, branches Claude created, and routine pushes to the default branch; the current default is broader.)

There are still guardrails inside that: a branch whose name marks it as a deploy target (`production`

, `release`

, `gh-pages`

) is judged on its own terms, including as a production deploy. Force pushes, a secret entering the commit, and history rewrites stay soft-blocked.

**Soft blocks can be cleared by explicit intent.** The classifier distinguishes "clean up the repo" (does not authorize a force-push) from "force-push this branch" (does). General requests don't count as explicit intent; naming the exact action does.

**Narrow allow rules bypass the classifier entirely.** A rule like `Bash(npm test)`

carries into auto mode and resolves *before* the classifier — only broad rules like `Bash(*)`

are suspended. A narrow prefix rule can therefore let a destructive argument through unseen. If you want every shell command classified regardless of your allow list, set:

```
{
  "autoMode": {
    "classifyAllShell": true
  }
}
```

(Requires v2.1.193+. It trades latency for coverage.)

If you like auto mode for everything except pushes and PRs, add content-scoped ask rules — they're evaluated before the classifier and always prompt:

```
{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}
```

For a boundary that must *never* be crossed, use `permissions.deny`

(ideally in managed settings for a team). Stating a boundary in chat ("don't push until I review") also works — the classifier reads it — but it can be lost when context compaction removes the message. Use an ask or deny rule for anything durable.

Per session: press `Shift+Tab`

to cycle modes, or start with `claude --permission-mode manual`

.

As a persistent default, set it in `~/.claude/settings.json`

:

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

`manual`

is the alias for the config value `default`

(v2.1.200+; both work). One placement gotcha: `"defaultMode": "auto"`

is **ignored** when it comes from a repo's `.claude/settings.json`

or `.claude/settings.local.json`

— since v2.1.142 a repository cannot grant itself auto mode. Your own opt-in or opt-out belongs in user settings. (If you're unsure which of your settings files wins, I wrote up [the full precedence order](https://dev.to/rulestack/claude-code-settings-precedence-which-of-your-five-settings-files-actually-wins-5133).)

Org admins can disable auto mode for everyone by setting `permissions.disableAutoMode`

to `"disable"`

in managed settings.

Auto mode denials are recorded: open `/permissions`

and check the **Recently denied** tab. Press `r`

on a denial to let Claude retry it. Repeated denials for the same destination usually mean the classifier doesn't know that infrastructure is yours — name it in `autoMode.environment`

in user or managed settings, then verify with:

```
claude auto-mode config
```

`claude auto-mode defaults`

prints the built-in rule lists, and `claude auto-mode critique`

reviews custom rules you've written. One warning from the config reference: if you set `environment`

, `allow`

, `soft_deny`

, or `hard_deny`

without including the literal `"$defaults"`

entry, you **replace** the entire built-in list for that section — including the force-push and `curl | bash`

soft blocks. Keep `"$defaults"`

in the array unless you intend to own the whole list.

Auto mode's classifier also changes plan mode: with auto mode available, the `useAutoModeDuringPlan`

setting is on by default, so shell commands during planning are reviewed by the classifier instead of prompting you. If you want the exact semantics of what plan mode blocks and what approving a plan switches you into, that's [yesterday's post](https://dev.to/rulestack/claude-code-plan-mode-what-it-actually-blocks-what-still-runs-and-what-approving-switches-you-22m3). And if your mental model of allow/ask/deny matching is fuzzy, [this one covers the rule syntax](https://dev.to/rulestack/claude-code-permission-rules-how-allow-deny-and-ask-actually-match-1bj7).

The honest framing from the docs themselves: auto mode reduces prompts, it doesn't guarantee safety. Trust it with tasks where you trust the general direction — and put ask rules on the actions you'd want to see either way.

*I maintain Rulestack — tested rules packs and skills for Claude Code, Cursor, and Codex, kept in sync with changes like this one. For a daily changelog-watch on AI coding tools, follow @ai-shop.bsky.social on Bluesky.*