Friday, Claude Code stops asking for your permission. And the number that comes with it hurts.

On August 14, two days from now, auto mode will become the default setting for Claude Code for Pro, Max and Team plans. In plain English, no more little window asking whether you authorize a command. The tool decides and executes it.

My first reaction was probably the same as yours. Wait, what? They're taking away my button?

Then I read the figure published by Anthropic in its announcement. I immediately felt a little less clever.

Somewhere in the pile, there's the command that wipes everything. He said yes.

You click yes 97 times out of 100

97%. That's the proportion of authorization requests users approve. Not 60. Not 80. Ninety-seven.

In other words, this famous safeguard doesn't control much anymore. It's a “next” button with one extra step.

Anthropic conducted a study with 1,053 paid testers. Both groups received the same set of dangerous actions. Result: human approval blocked 143 of them. Auto mode blocked 937.

The blue bar is us. Let's just say it's the end of the day.

And this isn't only true in the laboratory. In real sessions in May and June, serious, unintended damage occurred in 6.3% of manually approved sessions, compared with 2.4% in auto mode. More than twice as much, and not in the good direction.

The problem has been known for a long time. It's called approval fatigue. It's what happens with cookie banners, terms of service and authorization requests on your phone. After the third request, your brain stops reading. Your hand, however, keeps clicking.

Okay, so what does it block now?

Auto mode doesn't remove control. It changes the controller. Every action goes before what Anthropic calls a classifier. It's a second instance that examines what the tool is about to do, then decides whether or not to allow it. Its instruction is simple: block anything irreversible, destructive or directed outside your environment.

The bouncer doesn't read your code. It looks at what you're carrying.

In concrete terms, some actions remain prohibited without exception, such as sending code or secrets outside. This rule cannot be lifted either with an option or by insisting. Other actions remain blocked unless you explicitly request them. This applies to force-pushing, which forcibly rewrites Git history, deleting remote branches or tags, rewriting history, the famous curl | bash and production deployments.

The nuance around the word “explicitly” is a nice one. It even appears in the documentation. Asking Claude to “clean up the repository” doesn't authorize it to perform a force push. Asking it to “force-push this branch” does. A vague request isn't consent. That's also a good rule for life.

Another well-thought-out detail: by default, the classifier only trusts your working directory and remote repositories that have already been configured. Your company bucket, internal GitLab, or private package registry? Not recognized. They are therefore considered external and remain blocked until you declare them.

The Trap Nobody Will Read

There is one. And it is nasty.

When auto mode is active, your general authorization rules, such as the one that allows everything in the terminal, are set aside. That makes sense, since they would bypass the classifier. More specific rules, however, those that authorize a particular command, remain prioritized. The problem is that a specific rule authorizes a command prefix, not its result. If the command receives a dangerous argument that the rule did not anticipate, it goes through without being examined.

All that security budget, and the service door was left open.

The workaround is a single configuration line to add to your personal settings file:

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

This setting forces all terminal commands to go through the classifier, including those that already have authorization. You lose a little time with each command, since you have to wait for its decision. Personally, I prefer it that way.

Second point, and this one deserves applause. The classifier does not read settings placed in the project folder. It only consults those from your account and those deployed by your company. The reason is stated clearly in the documentation. Otherwise, a cloned repository or a simple build step could add its own authorization rules and give itself the green light. Someone at Anthropic thought about poisoned repositories. That is reassuring.

How to Stay in Control, Four Ways

If you want human approval before every code submission, a rule can take priority over the classifier and display the prompt every time. Add this to your settings:

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

This is what I use. Everything else runs in auto mode. The only thing that wakes me up is the moment my work leaves my machine.

To change modes on the fly, Shift+Tab cycles through the modes in the terminal. To see which rules the classifier is actually applying for you, use this command. It is more useful than it looks:

claude auto-mode config

It displays the rules actually being applied—that is, yours after being merged with the original ones. You can also use claude auto-mode defaults to view the built-in rules and claude auto-mode reset to reset everything after tinkering too much.

Careful, because this error can be costly. If you write your own list of rules without keeping the "$defaults" entry, you replace the entire original list. That includes the rule preventing data exfiltration. You thought you were adding one line. You just deleted thirty.

One last useful reflex: when an action is denied, type /permissions and check the recent denials tab. You can indicate that an action should be retried. That's better than disabling everything because you've decided the gatekeeper is too stupid.

And then there's the layer above, the one I haven't mentioned yet and that you write yourself: hooks.

A hook is a piece of script that Claude Code runs before using a tool. It comes before authorization rules, before the classifier, before everything else. Auto mode does not disable it. The documentation specifies that the hook receives the current mode among its input data, including "auto". You don't pass a parameter to something you don't execute.

The difference is simple. The classifier is a model tasked with making a decision. It reads the intent, analyzes the context for a few hundred milliseconds, and can make mistakes. A hook, on the other hand, doesn't judge anything. Fifteen lines look at a file path and answer no. No opinion, no nuance, no fatigue. And not a token spent.

I have two. They're exactly the ones you imagine. The first blocks any attempt to read an .env file, a .pgpass file, an SSH key, or the credentials file. Regardless of the mode or the reason, even if I ask nicely. The second requires my approval before every git push. An authorization never applies to the next attempt. And it works. While writing this article, I wanted to reread a documentation file stored in the wrong place. My own script sent me packing. Three seconds of annoyance, then I was rather pleased.

In the settings, it takes just a few lines:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Edit|Write",
        "hooks": [
          { "type": "command", "command": "~/.claude/hooks/block-secrets.sh" }
        ]
      }
    ]
  }
}

The script exits with status code 2, so the tool is not launched. If there's only one sentence to remember, it's this: when you already know what must never happen, don't ask a model for its opinion. Write three lines of script.

And if you don't code, it still concerns you

This 97% figure doesn't only concern developers. It concerns you too.

How many times have you accepted terms of use without reading them? Clicked “accept all” to make a cookie banner disappear? Given an app access to your photos, your location, and your contacts because it refused to open otherwise? You did exactly what those developers did. You approved it so you could continue.

The real lesson is that the checkbox was never really there to protect you. It mainly serves to transfer responsibility. If something goes wrong, someone can say that you had accepted. A protection that lets nine out of ten dangers through isn't protection. It's a legal umbrella.

So when a machine does better than our mindless click, we have to acknowledge it. Even if it stings a little.

What I think

The numbers are stubborn, and I believe them. Boris Cherny, the person in charge of Claude Code, says that he and his team have been using auto mode exclusively for months. Honestly, I've already been using it too.

What bothers me isn't auto mode. It's the word “default.”

As long as I choose, I take responsibility. When the setting is enabled for everyone and the question no longer arises, responsibility becomes unclear. If something goes wrong, we will always end up hearing, “It was the factory setting.” That said, if you had already chosen your mode, it remains in place. You are only asked once whether you want to switch.

So on Friday, I’ll see how it goes. I’ll keep my rule about code shipments. I may be convinced by the study, but not enough to let my work go out without looking up.