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 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.)
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. And if your mental model of allow/ask/deny matching is fuzzy, this one covers the rule syntax.
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.