Claude Code 5 min read

Claude Code Now Just Does It: Why Anthropic Flipped Autonomy On by Default

If you have used an AI coding assistant, you know the ritual. A dialog for every file read. Another for every shell command. The first few feel reassuring. By the tenth, you are hammering Enter without reading a word. That habit is exactly what Anthropic just designed around: Claude Code now runs autonomously by default, with a sandbox as the safety layer instead of a permission prompt.

One caveat up front. There is remarkably little community discussion of this shift — searches across the last month turn up almost nothing on Reddit. So this is not a read on developer sentiment. It is a look at why the design changed and what it costs.

Approval Fatigue Was the Real Bug

Prompting for every action is safe in theory. The user reviews everything. The problem is that people do not behave that way.

Security folks have known this for decades: show users enough warnings and they learn to dismiss warnings, not read them. Browser certificate errors are the canonical case. A mechanism built to communicate risk degrades into a reflex click.

The math is brutal for coding agents. A single refactor might need 40 file reads, 5 test runs, and 1 commit. That is 46 dialogs. By the third, nobody is reading. By the tenth, they hit Allow all. What is left is a review process that nobody reviews. The safety the approval model promised was substantially fictional from the start.

Moving the Control Point

So the design flips. Instead of asking whether each action is permitted, build a space where dangerous actions are not possible.

That is the sandbox. Run the agent inside an isolated environment — a Docker container, typically — and whatever happens inside stays inside. Deleted files are copies. Network requests only reach allowlisted destinations. Throw away the container and the mess goes with it.

What changed is the control point. The old model put a gate on every individual action. The new model draws one boundary and leaves the interior loose. It is airport security: clear the checkpoint once and you do not show ID again at every gate. A clear perimeter buys you a relaxed interior.

What Agents Can Do When You Stop Interrupting Them

Removing approval waits does not just make things faster. It changes what kind of work an agent can attempt.

The big unlock is trial and error. Until now, agents optimized for getting it right on the first try, because a wrong guess meant a rejected prompt and a dead conversation. Give an agent an isolated environment and no approval gate, and it can run tests, watch them fail, fix the cause, and run them again — no human in the loop. Which is precisely how developers actually work.

The shape of the interaction changes with it. You hand over an issue and walk away. The agent explores the codebase, edits, tests, fixes failures, re-tests. Twenty minutes later you come back to a finished change and a diff. You review once — and it is an actual review.

One meaningful review beats 46 reflexive clicks. That is the whole argument.

The Parts That Still Nag

None of which makes this comfortable.

Start with the sandbox itself. Container escape vulnerabilities are real, and a sloppy mount config exposes host files directly. Most developers adopted containers for reproducibility, not isolation. Repurposing them as a security boundary raises the bar considerably, and plenty of existing setups will not clear it.

Credentials nag harder. To do real work, an agent needs repo access, package registry tokens, sometimes API keys. If those live inside the sandbox, the isolation only covers the filesystem. An agent steered by prompt injection pushing code with a valid token is not a problem any container solves. Docker keeps a rogue process from touching your host; it does nothing about a legitimately authenticated one doing the wrong thing.

And the review burden simply moved. The dialogs are gone, but now you have to read the final diff — and how many people seriously read a 300-line change? Approval fatigue could just get a new name: review fatigue.

Defaults Are a Statement

In software, a default is not just an initial setting. It is what most users run forever, and it is where the maker declares what normal usage looks like.

Shipping autonomous execution as the default is Anthropic saying that delegating work to an agent is the standard case, not the exception. Burying it behind a flag and turning it on out of the box are entirely different claims.

Competitive pressure is surely part of it. With several high-autonomy coding agents on the market, a tool that keeps interrupting you feels obsolete fast. But Anthropic absorbed that pressure and shipped a containment story alongside the loosened reins, which is at least the right order of operations.


Anthropic concluded that the approval model never delivered the safety it advertised, and moved the control point from individual actions to the execution environment. The problem statement is correct. Whether the sandbox holds, and how the credential problem gets handled, are open questions that real usage will answer.

The more interesting question is what we are actually protecting when we hand code over to an AI. Is it accidentally deleted files? Or is it unreviewed code we do not understand landing in the repo? Sandboxes are excellent at the first one. The second is still entirely on us.

Claude Code AI agents sandboxing developer tools security

Comments

    Loading comments...