AI-generated conceptual illustration; not a product interface or measured security result.
Anthropic says Claude Code will start new sessions on Pro, Max and Team plans in auto mode from August 14, 2026. The change reduces routine permission prompts, but it does not silently override every existing user or organization setting.
According to Anthropic’s August 7 announcement, a default selected by a user remains in place unless that user accepts a one-time prompt to switch. A pinned default does not change, and a default set by a Team administrator through managed settings also remains unchanged.
The rollout changes Claude Code’s starting permission mode for a defined group of new sessions. It does not make auto mode mandatory, eliminate other permission modes, or establish that automated classification is a substitute for human review.
The August 14 default has a limited scope
Pro, Max and Team users who have not selected another default will receive an in-product notice, and their new sessions will begin in auto mode. Users can still switch permission modes during a session or configure another default.
Enterprise sessions and sessions using the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud’s Agent Platform or Microsoft Foundry remain opt-in for now. Anthropic says it plans to make auto mode the default across those environments later, but that is a stated roadmap rather than the current starting behavior.
Availability and default status are separate questions. Auto mode can be available on a supported account, model and provider without being the mode in which a session starts. Enterprise administrators can also select auto mode through managed settings before Anthropic changes the broader default.
Teams should therefore check both the effective user setting and any organization-managed policy rather than infer the active mode from plan eligibility alone.
Auto mode inserts a classifier into the permission path
Auto mode is not equivalent to running Claude Code with its permission checks bypassed. It retains a permission system while reducing the number of actions that require an immediate human response.
Claude Code first evaluates its standard permission rules. Explicit permissions.deny rules block matching actions before the classifier is consulted, while content-scoped permissions.ask rules force a prompt. Narrow allow rules can also resolve permitted actions early, although Claude Code sets aside broad allow rules that would grant arbitrary shell or interpreter execution while auto mode is active.
Read-only operations and ordinary edits inside the working directory can proceed without a classifier call. Other actions reach a classifier that evaluates the pending tool call against the user’s request, the action’s likely impact and the configured trust boundary.
Anthropic’s engineering explanation describes the classifier as a gate for actions that may be destructive, irreversible, externally directed or broader than the user authorized. A separate prompt-injection probe screens incoming tool results before the main agent processes them.
When the classifier blocks an action, Claude receives the denial and can try a safer path. It may also ask the user to authorize the action directly when it cannot proceed safely.
Repeated blocks return control to the user
The classifier is not allowed to reject actions indefinitely while the session continues unattended.
The current Claude Code permission-mode documentation says auto mode pauses after three consecutive classifier blocks or 20 blocks across a session. Claude Code then resumes manual permission prompts. An allowed action resets the consecutive counter, while the session-wide counter continues until its threshold triggers.
Approving the prompted action resumes auto mode. In a non-interactive claude -p run, repeated blocks terminate the session because no user is present to answer the fallback prompt.
These limits provide a backstop, but they can also reveal missing environment context. A workflow that repeatedly targets an internal repository, service or bucket that Claude Code does not recognize may encounter avoidable denials until its trust boundary is configured.
Teams can define what counts as trusted infrastructure
By default, the classifier trusts the working directory and the current repository’s configured remotes. Other repositories, domains, cloud buckets and services may be treated as external until they are declared.
The autoMode.environment configuration lets users and administrators describe trusted source-control organizations, internal domains, cloud buckets, package registries and other infrastructure. These entries are written as natural-language descriptions rather than regular expressions.
Organizations can layer explicit permission rules on top. For example, permissions.ask can preserve a human checkpoint before every push or pull-request creation, while permissions.deny can prohibit an action regardless of classifier judgment.
Administrators should inspect the effective configuration before rollout and retain the built-in defaults unless they have deliberately reviewed replacements. In the autoMode rule arrays, omitting the documented "$defaults" entry can replace an entire built-in list rather than extend it.
Auto mode still requires an operational review boundary
Anthropic says auto mode reduces risk but does not eliminate it. The classifier can allow a risky action when context or intent is ambiguous, and it can also block a benign action.
The company has published testing and customer results as part of its rationale for the rollout. Those figures are vendor-reported and do not independently establish that auto mode is safer or more productive for every repository, organization or workload.
Before August 14, teams should inventory user and managed defaults, add durable ask or deny rules around consequential operations, define trusted infrastructure narrowly and test the mode in non-production environments. High-stakes changes to production infrastructure, credentials, access controls or shared data still warrant direct human review.
The practical change is fewer routine prompts for eligible new sessions—not the removal of accountability for what the agent executes.
