Claude Code Auto Mode Explained in 7 Minutes

The 93 percent approval problem

Every time Claude Code wants to run a command, it stops and asks for approval. Approve or deny. Approve or deny. Anthropic's own research says people approve 93 percent of those prompts.

That is a lot of clicking for a button you almost never read. So what if the button could click itself, but only when it is safe to? That is auto mode. Anthropic introduced it in March 2026.

Here is how it decides what runs, what stops, and what never gets to run at all.

The problem: approval fatigue vs no guardrails

Start with the problem. Claude Code's default is safe in a way that gets old fast. Every file write and every shell command asks first. That is fine for a five minute change and miserable for a two hour task.

So people do one of two things. Some turn off every check with the dangerously skip permissions flag and walk away. There is no review left after that, and Anthropic says that flag should not be used outside isolated environments. Others just approve faster and faster until they are not reading anymore.

That is approval fatigue, and it is how real incidents happen. Auto mode is the middle path between those two doors.

The permission modes side by side

Here is the whole family. Manual mode reads files freely and asks for everything else. Accept edits mode also lets it change files in your project and run simple file commands, but still asks before the rest. Plan mode lets it explore and write a plan without touching your code.

Auto mode runs everything with a background safety check. Don't ask mode allows only what you pre-approved and denies the rest. And bypass permissions runs everything with no checks at all. Auto mode is the only one of these where a second model, not you, makes the call.

You switch between them with Shift plus Tab. The status bar shows auto mode on when you are in it.

Auto mode is a second reviewer, not Claude

Here is the part people get wrong. Auto mode is not Claude approving itself. Anthropic compares that to writing, reviewing and merging your own pull request. Instead, when Claude proposes an action, a separate classifier model reviews it.

And it reviews it on purpose half blind. It sees your messages and the commands Claude wants to run. It does not see Claude's explanations, and it does not see the output of the tools. That is by design.

If it could read Claude's reasoning, Claude could argue its way past it. And if it read tool output, a web page could hide instructions inside it. The default classifier model is Claude Sonnet 5.

The three step decision ladder

Here is the order a decision goes through. Step one, your own rules. If you have written allow, ask or deny rules, they are evaluated before anything else, and a deny rule cannot be overridden by anyone. Step two, the boring safe stuff.

Reading files and editing files inside your working directory are approved automatically, with no classifier call and usually no extra latency. Those edits are still reviewable in your version control afterwards. Step three, everything else goes to the classifier: shell commands, web fetches, anything outside your project, anything that deletes something. And one detail matters.

When you enter auto mode, Claude Code drops your broad allow rules, the ones that say allow any shell command or allow any Python script. If those stayed, the classifier would never see the most dangerous commands.

What the classifier blocks, and what it allows

So what does the classifier actually block? By default it blocks downloading and running code in one step, the classic curl, pipe to bash. It blocks sending sensitive data to outside endpoints. It blocks production deploys and database migrations.

It blocks force pushing. Mass deleting things in cloud storage. Granting permissions. Writing to a secret manager.

Changing DNS records. Destroying infrastructure with Terraform. Merging a pull request that no human approved. And deleting files that existed before the session started.

And by default these are allowed. Local file work in your project. Installing dependencies that are already in your lock file. Read only web requests.

Sending environment file credentials to their own API. And pushing to any branch of the repo you are working in.

When the classifier says no

Here is what happens when the classifier says no. It does not just stop the task. The denial comes back to Claude with the reason, and Claude tries to find a safer path on its own. If a force push gets blocked, it might push to a new branch instead.

If the same action gets blocked three times in a row, or twenty times across the whole session, auto mode pauses and starts asking you again. Approving that prompt puts you back in auto mode.

The trust boundary you configure

Nothing is silently failing, and nothing is silently succeeding. Here is the setting that trips people up. By default the classifier trusts exactly two things: the folder you are working in, and the remotes that repository was configured with. Everything else looks external.

That includes your own company GitHub organisation, your own cloud buckets, your own internal services. So the first thing Claude tries to do inside your company gets blocked, and you end up adding a line to your settings explaining your infrastructure. You can write that yourself in plain English, under the auto mode environment setting. Or you can run slash auto mode setup and let Claude draft it from your project and your recent sessions.

Then run claude auto mode config to see exactly what the classifier is using.

A full run, step by step

Watch it work. You ask Claude to refactor the checkout module and update the API documentation. It reads the files, approved instantly. It rewrites the module, also approved.

It runs the test suite, that goes to the classifier and passes. It fetches a documentation page, that goes to the classifier too, and the page content gets scanned first, because a web page can carry hidden instructions. Then it decides the documentation should be published, and it tries a deploy command. Blocked, because production deploys are on the list.

Claude does not argue. It writes the docs to a local folder instead and tells you what it did.

The honest numbers, and when not to use it

You walk away. You come back later. Now the honest part, because Anthropic published the numbers. They ran the classifier over ten thousand real tool calls from their own engineers.

On harmless actions, the false positive rate was zero point four percent, so almost no false alarms. But they also collected fifty two real cases where Claude went too far, and on those, 17 percent of the dangerous actions got through. Anthropic calls that the honest number. The classifier usually spots the danger.

What it cannot always tell is whether an earlier yes from you really covers this specific action. So this is not a replacement for reviewing anything that matters.

Turn it on, and the recap

Anthropic still says to use it in an isolated environment for high stakes work, and for production infrastructure they say review the actions yourself. So how do you turn it on. Press Shift plus Tab until the status bar says auto mode on. Or start a session with the permission mode auto flag.

Or set the default mode in your home settings file, because the project level settings file will not take it. 6 or newer on the Anthropic API, and an admin can switch it off for a whole organisation. Here is the recap. Manual mode asks you every time.

Bypass permissions checks nothing. Auto mode puts a second model in the loop that reads your intent, blocks what reaches past it, and hands the hard calls back to you. If this helped, subscribe. Everything on this channel is built with these tools, for real.