On 7 August, Anthropic announced that from 14 August, new Claude Code sessions on Pro, Max and Team plans will run in auto mode. Instead of asking me to approve each tool call, it routes every one through a classifier "targeted at blocking actions that are irreversible, destructive, or aimed outside your environment".
I sat down to write the case against it. I had the argument ready, because I have been the human on the other end of those prompts for months and I know what I do with them.
Then I read the study in the announcement, and the argument I wanted to have was already over.
The number that ended the argument I wanted to have
Anthropic ran a controlled study with 1,053 paid testers. They planted a dangerous command in a normal working session and measured who caught it.
Human review, the thing I was about to defend, caught 13.6% of them. Auto mode caught 89%. Head to head, "auto mode blocked 800 commands that a human approved, while humans blocked only 6" that auto mode allowed.
What happens across a session landed harder than the headline. Testers "blocked about 17% of dangerous commands early in a session, dropping to about 5% after 50 or more prior prompts", while the classifier's block rate stayed flat.
And users approve 97% of permission prompts in Claude Code, which is the figure I cannot argue with at all.
That is me. I have approved thousands of these. I could tell you I read them, and I would be describing an intention rather than a behaviour.
None of this should have surprised me, because usable-security researchers have been measuring it for over a decade. Adrienne Porter Felt and colleagues found in their 2012 study of Android permissions that 17% of people paid attention to permissions during installation, and that only 3% of their survey respondents answered all three comprehension questions correctly.
Bonnie Anderson's group went further and put people in an fMRI scanner. They measured "a dramatic drop in the visual processing centers of the brain after only the second exposure to a warning". Not the twentieth. The second.
Habituation is what a nervous system does to a repeated stimulus, not a discipline failure that better training fixes. No amount of me promising to be careful this time argues with it.
The Anthropic study is vendor-published, gathered to support a decision they had already made, and I would like to see the methodology. But its direction agrees with both of the studies above, and I am not going to call a number wrong because it is inconvenient for the piece I planned.
I expected a keyword matcher and found something better
My second assumption was that the classifier would be a glorified allowlist, matching command shapes and missing everything else. The documented block list is more interesting than that.
It blocks the obvious things, curl | bash and force pushes and terraform destroy. It also blocks "committing or pushing a change that would send secrets or sensitive data outside the repository when it runs", which covers a CI workflow that hands a secret to a destination that does not already receive it.
That check "fires when the change lands, whether or not that landing triggers the pipeline". It blocks merging a pull request no human has approved, and it blocks Claude approving its own pull request.
Read that again, because it is doing something harder than pattern matching. It is reasoning about what a file will cause a different system to do later. That is a real model of consequence, and a better one than I expected to find.
So the piece I was going to write, the one where a dumb filter waves through anything it does not recognise, was wrong twice before I reached the second heading.
Then I read what happens to the boundaries I set myself
Deeper into the same page is the part I have not stopped thinking about.
The classifier treats boundaries you state in conversation as a block signal. Tell Claude "don't push" or "wait until I review before deploying", and it blocks matching actions even when the default rules would allow them.
Good. That is the mechanism by which I get to put my own knowledge into the system, the knowledge that this particular push is wrong today for a reason no repository contains.
Then the documentation says this: "Boundaries are not stored as rules. The classifier re-reads them from the transcript on each check, so a boundary can be lost if context compaction removes the message that stated it."
The sentence I said to protect myself lives in the conversation, and the conversation is what gets thrown away when the window fills up.
On a long session, which is exactly the session where I have stopped reading prompts and most need the boundary to hold, the earliest messages go first. My instruction is old by then. It goes early.
Anthropic tells you the fix in the next line, and it is the right one: "For a hard guarantee, add a deny rule instead." I had read past that line twice before I understood it was the whole article.
Everything that ever cost me was allowed
The 89% measures something specific, because the study planted a dangerous command and then went looking for it.
Almost nothing that has ever hurt me looked dangerous. The pushes that cost me an afternoon were ordinary pushes. The revert that made things worse was a correct revert applied to the wrong branch. The change that shipped something I did not want public was three lines that were individually fine.
Every one of those would pass a review that asks whether an action is destructive, irreversible, or aimed outside my environment, because the answer each time was no. They were wrong because of when they happened and what else was true at that moment, and neither of those is a property of the command.
I know this well enough that I built around it years ago. I have a rule that I never commit directly to main, and because a rule I merely believe in is not a control, there is a hook on my machine that refuses a push when the branch does not look right.
It has stopped me more than once. It has never once stopped me because the push itself was dangerous. It stopped me because I was on the wrong branch, which no classifier can know is wrong, because on any other Tuesday it would have been right.
One default moved twice in eight days
Which brings me to a line in the docs I would have skimmed a month ago.
Pushing to any branch of the repository you are working in, including the default branch, now runs without a prompt in auto mode. The same page records how it got there.
Before v2.1.211, only pushes to your starting branch, branches Claude created, and routine pushes to the default branch were allowed. Before v2.1.203, any direct push to the default branch was blocked outright. Those versions are dated 15 July and 7 July in the changelog. Blocked, then partly allowed, then allowed, in eight days.
I want to be fair about this. Deny rules still block pushes to specific branches in every mode, the remote's own branch protection still applies, and a branch named as a publication target like production or gh-pages is judged on its own terms.
This is a deliberate loosening by people who watched the false positives pile up, and the docs are unusually honest about the tradeoff. They warn that auto mode "does not guarantee safety", and they pause it after the classifier blocks three times in a row or twenty times total.
The point is the direction. Defaults move, they move toward less friction because that is what the complaints are about, and the thing that does not move on its own is my configuration. If my only stated boundary was a sentence I typed in March, I have been relying on something with no version history at all.
Cursor wrote the first half of this in June
I am not the first to notice that context decides risk. Cursor published exactly this on 11 June: "Whether an agent action poses risk depends on the situation. The same command can be harmless in one workflow and unacceptable in another."
Their answer is that the classifier should read the workspace before deciding, and Anthropic's does something similar. I think that solves the smaller half of the problem.
Everything a classifier can read is something the repository already knows. The context that makes an ordinary action wrong is usually the context nobody wrote down: that the client call moved, that I am mid-migration, that this branch is a dead end I have not deleted yet.
And when I do write it down, I write it in a sentence, in a conversation, in the one place in the system with an eviction policy.
What I actually changed
I left auto mode on. Given a 13.6% and a 97%, turning it off to hand the decision back to a habituated human would be a preference dressed as a principle.
What I moved is where my boundaries live. Anything I care about is now a deny or ask rule in ~/.claude/settings.json rather than an instruction I state and hope survives.
It has to be the user settings file, because since v2.1.142 a repository's own .claude/settings.json cannot grant auto mode, which tells you what Anthropic thinks about trusting a file that arrives alongside the code. They are right about that too.
And I kept the one gate that has always worked, which is a gate on the outcome rather than on the keystroke. This article was researched, drafted and committed by an unattended pipeline that runs three mornings a week while I am doing something else. It has no human approving its tool calls, by design.
It also cannot merge its own pull request, and that boundary is not a sentence in a transcript. It is a rule, in a file, that will still be there in November.
The classifier earned the win. It is better than I am at the question it was built to answer, and I have the receipts for how bad I am at that question. But the prompt was never really my control. It was a place where I could have paid attention, and the evidence says I was spending that attention 97 times out of a hundred on the word yes.
