~/beer-and-code
▪ next event Workshop: Jev na Prática para Devs · 14 Oct · 19h — duração de 2h a 3h, ao vivo via Google Meet save your seat ›
~ / news / claude-code-auto-mode-default $
News

Claude Code Auto Mode: What It Is, How to Turn It On/Off, What It Allows

LS Lucas Souza · · 8 min read
Claude Code Auto Mode: What It Is, How to Turn It On/Off, What It Allows

On August 14, Claude Code stops asking you.

It's not a new mode. auto has been around since March. What changes on the 14th is that Claude Code's Auto Mode becomes the default: anyone on Pro, Max, or Team will open the terminal and find the session already running with a classifier deciding, on your behalf, which commands get to execute. You don't have to do anything for that to happen. You have to do something for it not to happen.

Anthropic justified the change with an uncomfortable number: in a test with more than a thousand professional devs, the classifier blocked 89% of dangerous commands. Humans approving by hand blocked 14%. This post is about what that number means, what exactly auto mode lets through without asking — there's stuff on that list that will probably surprise you — and how to put the brakes back on without giving up the mode.

TL;DR

  • What it is: Claude Code's auto permission mode becomes the default. A separate classifier model evaluates every tool call before it runs, in place of the approval prompt.
  • When and for whom: August 14, on Pro, Max, and Team. Enterprise, API, Bedrock, Google Cloud Agent Platform, and Microsoft Foundry stay opt-in, with the switch expected over the following month.
  • Cost: the classifier's extra tokens no longer count against the usage limit on Pro, Max, and Team.
  • How to get out: Shift+Tab in the session, defaultMode in user settings, or disableAutoMode in managed settings if you're an admin.
  • Useful link: Choose a permission mode and Configure auto mode — the Portuguese documentation is the real reference, not the news posts.

What changes when Auto Mode becomes the default in Claude Code

Today, in Manual mode (the default value in the config), Claude stops at every file write and every shell command and waits for you to hit yes or no. Starting on the 14th, the default becomes auto: the pause goes away for routine work and every action goes through a classifier model that runs before execution.

The first thing to understand is that auto is not bypassPermissions. They're opposites, and the difference is worth locking in:

Mode What runs without asking
default (Manual) Reads only
acceptEdits Reads, file edits, and common filesystem commands
plan Reads only
auto Everything, with a background safety check
dontAsk Pre-approved tools only
bypassPermissions Everything, with no check at all

bypassPermissions is --dangerously-skip-permissions: there's no check, it's meant for an isolated container. auto swaps your approval for an automated one — which can say no. The documentation itself is honest about the limits of that: "auto mode reduces permission prompts, but does not guarantee safety".

The classifier runs on a server-defined model, regardless of what you picked in /model. It sees your messages, the tool calls, and the contents of your CLAUDE.md. And it deliberately sees one thing less: tool results are stripped before they reach it, so that hostile content inside a file or a web page can't manipulate it directly. A separate server-side probe is what inspects those results before Claude reads them.

Keeping up with every one of these switches on your own is what wears you down: the default of a tool you use every day changes on a Thursday and you find out later, in production. In the Clã Beer and Code we open up the config and talk through what changes the same week it changes — it's a paid subscription, no euphemism, and it's the kind of environment a silent default change calls for.

Anthropic's numbers — and the 11% the press put in the wrong place

The core argument for the change is a study with 1,053 paid professional testers. The result:

Who approves Dangerous commands blocked
Human, approving by hand 13.6% (the official announcement rounds it to 14%)
Auto mode classifier 89%

Anthropic adds that, looking at real sessions, manual approval was more than twice as likely to end in a harmful action the user hadn't explicitly asked for. In simulated attacks, the failure rate dropped from 12% to 7%. And an independent evaluation by Trajectory Labs couldn't land a single one of the 720 prompt injection attacks it tested. The trade press read it with polite skepticism: The New Stack summed up the decision as "because humans can't be trusted".

A warning here about what you've read elsewhere over the last few days. The line "the AI catches 89% and humans catch 11%" got passed around a lot. That 11% isn't the human rate — it's 100 - 89, meaning what the classifier lets through. The human rate is 13.6%. Two different numbers, with opposite meanings, became one in a bunch of headlines.

Why this matters in practice: the 11% the classifier gets wrong is your actual residual risk. It's not anyone's performance. Read it the wrong way and you'll think auto mode is an absolute security upgrade, when what it really is is a trade — you stop being the bottleneck and become the audit.

And then there's the detail almost nobody mentioned: Anthropic stopped charging for the extra tokens the classifier consumes on Pro, Max, and Team, and intends to do the same on the other platforms. Note that the documentation still states that "classifier calls count toward your token usage" — on this point it's lagging behind the announcement. If you'd been avoiding auto mode for fear of burning through your quota, that reason is gone. (Where your quota actually goes is a different topic: prompt caching.)

What auto mode allows by default

This is the section that makes the whole post worth reading. Allowed without asking:

  • Local file operations in your working directory.
  • Installing dependencies declared in your lockfiles and manifests.
  • Reading .env and sending the credentials to the matching API.
  • Read-only HTTP requests.
  • Pushing to the branch you started on, or one Claude created.
  • Routine pushes to the repository's default branch.

Read the two in bold again.

Pushing straight to the default branch has been allowed since v2.1.203 — before that, any push to the default was blocked. Today the classifier only steps in when the push carries risk: force push, sensitive content like secrets or personal data, changes that are hidden or poorly described relative to what you asked for, content pulled in from outside the repository, or a push that bypasses a review you set up yourself. An ordinary push to main goes through.

If your workflow depends on "nobody commits straight to main," the remote's branch protection still applies — the classifier is one layer, not the only one. But if you were counting on the Claude Code prompt as your checkpoint, it won't be there anymore.

▪ Clã Beer and Code

Do not just follow the news — master it. Hands-on AI Engineering, live, every week, in the largest community in Brazil.

Join the Clã

What it blocks

The block list is long and has grown a lot over the last few versions. The highlights:

  • Downloading and executing code, like curl | bash.
  • Sending sensitive data to external endpoints.
  • Production deploys and migrations.
  • Mass deletion in cloud storage.
  • Granting IAM or repository permissions.
  • Force push; git reset --hard, git checkout -- ., git clean -fd, git stash drop.
  • git commit --amend when the commit at HEAD wasn't created in this session, or has already been pushed.
  • terraform destroy, pulumi destroy, cdk destroy.
  • Merging a PR no human approved, or Claude approving its own PR, or disabling CI checks.
  • Turning on, turning off, or ramping a production feature flag.
  • Printing a live credential or token to the transcript or to a file.
  • Running a command with a flag that turns off a protection, like --insecure.
  • Writing to its own session transcripts in ~/.claude/projects/.
  • Sending keystrokes to Claude Code's own tmux pane — which the classifier treats as Claude tampering with its own oversight.

Two things never even reach the classifier: rm -rf / and rm -rf ~ go straight to the approval prompt, including when they show up inside $(...), backticks, or <(...).

And there's a mechanism almost nobody knows about: a boundary you state in conversation blocks too. If you write "don't push until I review," the classifier starts blocking the matching actions even if the default rules would have allowed them. The catch is that this doesn't become a stored rule — it rereads the transcript on every check. If context compaction eats the message where you stated the boundary, the boundary evaporates with it. For a hard guarantee, it has to be a rule in a file.

How to turn off Auto Mode (or just put the human checkpoint back)

There are four levels, from the most surgical to the bluntest.

1. Keep auto mode, but require approval for specific actions

The mechanism is permissions.ask. Content-scoped ask rules are evaluated before the classifier and always force the prompt, even in auto mode. It's the recipe for anyone who wants the smoother flow without letting go of pushes and PRs:

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

If the action should never run, under any circumstances, that's permissions.deny — which blocks before the classifier is even consulted and can't be overridden, not even by your stated intent.

2. Tell the classifier what your infrastructure is

By default the classifier trusts only the working directory and the remotes that were already configured when the session started. Everything else is external — and a potential exfiltration target. That's why it blocks a push to your company's org or a write to a team bucket until you declare them:

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp e todos os repos abaixo",
      "Trusted cloud buckets: s3://acme-build-artifacts",
      "Trusted internal domains: *.corp.example.com",
      "Key internal services: Jenkins em ci.example.com"
    ]
  }
}

The entries are prose, not regex. The classifier reads them as natural-language rules — write them the way you'd explain your infra to someone who joined the team yesterday.

The gotcha that's going to catch a lot of people: the classifier does not read autoMode from .claude/settings.json or from .claude/settings.local.json. Those files live inside the repository, so a cloned repo could inject its own permission rules. autoMode only counts in ~/.claude/settings.json or in managed settings. Put it in the wrong place and it's silently ignored, and you'll think you configured it.

The same warning goes for "$defaults": setting environment, allow, soft_deny, or hard_deny without that literal string throws away the entire built-in list for that section. Without $defaults in soft_deny, you just turned off the blocks on force push, curl | bash, and production deploys without noticing.

3. Send every shell command to the classifier

Narrow rules like Bash(npm test) still apply in auto mode and resolve before the classifier. The problem is that a narrow rule still lets through a destructive argument the prefix didn't anticipate — a script path, an unexpected flag.

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

This suspends all Bash and PowerShell rules while auto mode is active. It trades latency for coverage: every shell command now waits on a decision.

4. Just don't use it

In the session, Shift+Tab cycles through the modes — auto shows up last in the cycle. To make it stick:

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

One detail: defaultMode: "auto" is ignored when it comes from project or local settings, precisely so a repository can't grant itself auto mode. manual, on the other hand, works in the normal scopes.

If you're an Owner on Team or Enterprise, the org-level control is permissions.disableAutoMode set to "disable" in managed settings. That takes auto out of the Shift+Tab cycle and makes --permission-mode auto get rejected at startup.

And three commands to check what you actually configured, instead of hoping:

claude auto-mode defaults    # imprime as regras embutidas
claude auto-mode config      # imprime a config efetiva, com $defaults expandido
claude auto-mode critique    # pede uma revisão das suas regras customizadas

Run config after you save. It's the only way to know whether that autoMode block is really being read.

Limitations and things to watch

The 7% is still there. In simulated attacks the failure rate dropped from 12% to 7% — dropped, not zeroed out. And the 11% of dangerous commands the classifier doesn't catch are real. Auto mode is good for work where you trust the general direction, not a substitute for review on a sensitive operation.

The classifier is blind to tool results. That's a design choice that protects against prompt injection, but it has a cost: it judges based on the conversation, not on command output. That's why an rm -rf "$VAR" whose value came only from earlier output gets blocked instead of evaluated — it has no way to resolve the target. If you want to understand the threat model behind this, check out the post on prompt injection and the main attacks of 2026.

It gives up on its own. If the classifier blocks an action 3 times in a row or 20 times total, auto mode pauses and the permission prompt comes back. The limits aren't configurable. In non-interactive mode with -p, repeated blocking aborts the session — there's nobody to ask. If you run Claude Code in CI, plan for that.

Subagents don't get a pass. The classifier checks at three points: the task description before the subagent starts, each of its actions during execution, and the full history on return. Any permissionMode in the subagent's frontmatter is ignored.

Broad rules get dropped. On entering auto mode, Bash(*), PowerShell(*), wildcard interpreters, and Agent rules are thrown out. They come back when you leave the mode.

Quick FAQ

Can I just stay in Manual mode? Yes. Shift+Tab during the session fixes it on the spot, and "defaultMode": "manual" in ~/.claude/settings.json makes it permanent. The manual alias for the default value exists as of v2.1.200.

I'm an admin and I don't want this at my company. Managed settings with permissions.disableAutoMode set to "disable". That removes the mode from the cycle and rejects the flag at startup — it's an organization control, not a suggestion.

Does it apply to people using Bedrock, Google Cloud, or Foundry? On the 14th, no. The switch is on Pro, Max, and Team; Enterprise, API, and the partner platforms stay opt-in and are expected to switch over the following month. On those providers auto mode only runs on Sonnet 5, Opus 4.7, and Opus 4.8.

Is the classifier going to eat my usage limit? Not on Pro, Max, and Team — Anthropic stopped charging for those extra tokens. The documentation still says the opposite in one passage; on this point it's out of date relative to the announcement.

The default changed. The responsibility didn't.

Anthropic's data point is real and it's uncomfortable: approving by hand, we catch 13.6% of dangerous commands. Nobody reads the thousandth prompt of the day carefully. Automating that decision is, on average, an improvement — and the 720 prompt injection attacks that didn't get through in the independent evaluation are no small thing.

But the average isn't your session. What determines your risk is what's on the allowed-by-default list: pushing to the main branch, reading .env, installing dependencies. If any of those three gave you a knot in your stomach while reading, you have four days and one JSON file to deal with it.

Open ~/.claude/settings.json today. Run claude auto-mode config and look at what comes out. It's cheaper than finding out on Thursday that your tool's definition of "routine" wasn't the same as yours.

If you want to see what happens when an agent decides on its own what's reasonable to do, the Claude that broke into three real companies is your next read. And if the topic is what Anthropic changes without telling you, there's also the 80% of Claude Code's system prompt that disappeared.

Lucas Souza
Written by
Lucas Souza

{AI Engineer} — apaixonado por Laravel, arquitetura de software e construir produtos com impacto. Compartilho aqui tutoriais, descobertas e reflexões sobre o dia a dia de engenharia.

▪ Clã Beer and Code

There is no shortage of content. What is missing is someone to untangle it: what matters now is how to implement it the right way. In the Clã you get that live, every week, with people who have already filtered out the noise.

Join the Clã
Meet the Clã Beer and Code
playing