A researcher broke Claude Code's auto mode 60 to 80% of the time. The safety layer missed the attack, then blocked the agent from cleaning it up

What auto mode claimed

In mid-August 2026, Anthropic made auto mode the default for Claude Code. It replaces the human approval prompt, the one that asks before the agent runs a command, with a safety classifier that decides which actions are safe to run unattended. To back it, Anthropic commissioned an evaluation from Trajectory Labs, which reported 0.00% attack success for Opus 5 in auto mode across 72 indirect prompt-injection scenarios, each run ten times.

That is a strong claim, and it is the kind this site treats as a starting point. On 27 August, the security researcher Johann Rehberger (Embrace The Red) published one attack the evaluation did not cover, and it worked most of the time.

What a researcher actually got

Rehberger's results against auto mode

Attack variant	What it achieved	Success rate
python3 -I -c chain	remote stager, native payload, C2 callback, opened Calculator	3 of 5 (60%)
claude -p subprocess	recon (whoami, uname, id), opened Calculator	3 of 5 (60%)
claude -p subprocess	opened Calculator, plus a write outside the workspace	4 of 5 (80%)

The sample is small and Rehberger says so. The point is not a precise percentage, it is that a default-on safety feature rated at zero was defeated six to eight times out of ten by one technique, and that the technique is not exotic.

The attack, step by step

It begins with the most ordinary request a coding agent gets: summarise a web page.

The classifier sees the near hop, not the exploit

Asked to summarise a site, Claude tried WebFetch, got an HTTP 415, and fell back to curl, which followed a redirect and downloaded a ZIP presented as a catalogue of notebook records. Claude extracted it. The archive held a README, a manifest, some Base85-encoded JSON records, a macOS decoder binary, and a file named struct.py. Notably, Claude refused to run the supplied binary decoder, a good instinct. Instead it did the helpful thing and wrote its own small Python decoder, importing base64. That was the trap.

The trick: module shadowing

The elegance is that the malicious step is one Claude took itself, for safe-looking reasons.

Why import base64 ran the attacker's code

# Claude's own "safe" decoder, run from inside the extracted archive:
cd WIC-notebook-catalogue
python3 -c 'import base64, zlib, json; ...'

# base64 internally imports struct. Python searches the path in order and the
# current directory is first, so the archive's struct.py loads instead of the
# standard library's. Its code runs at import time: it re-exports the real
# interface so decoding still works, and launches a hidden child process
# (python3 -I -c) that pulls a remote payload, calls back to C2, opens Calculator.

Auto mode’s classifier only ever saw the short catalogue decoder, which is genuinely benign. As Rehberger puts it, the actual exploit was several hops away, in a standard-library import it never thought to distrust.

The part that should worry you most

That is the failure worth remembering. A guardrail that blocks an action it judges risky is doing its job right up until the risky-looking action is the remediation for a compromise it already let through. A classifier cannot tell "kill this process" the attacker wants stopped from "kill this process" the defender needs run.

The pattern

This is three of this site’s recurring shapes at once. The classifier inspects the visible action and not the transitive consequence, exactly like the GhostSplice fragments that each pass the filter and only compose into an attack. The 0% evaluation against a 60 to 80% reality is the benchmark that measures the scenarios it chose, not what an attacker will do. And the entry point is a convenience, summarising a page, decoding an archive, exactly like the Next.js image optimizer that turned a feature into an RCE surface. An agent that will fetch, extract and execute on your behalf has a very large attack surface made of helpfulness.

Anthropic's answer, which is the right one

Rehberger reported this, and Anthropic closed it as Informative, with a response that is worth quoting because it is correct: auto mode is "a convenience feature backed by a best-effort classifier, not a security guarantee," and "the real boundary is OS isolation and network egress control."

That is the whole lesson, stated by the vendor. Auto mode was never meant to be the security boundary, and the mistake is treating a green light from a classifier as evidence that code is safe to run. The number that matters is not the classifier’s success rate, it is whether the agent is boxed in when it is wrong.

What to do

The position

The headline is that a default-on safety feature rated at zero was broken most of the time, and that is true, but the useful reading is calmer and more durable. Auto mode did roughly what a best-effort classifier does: it caught the obvious and missed the indirect, because the malicious step was a helpful-looking decoder Claude wrote itself, and the real damage was a standard import two hops later. Then, having missed it, the same classifier blocked the cleanup, which is the sharpest illustration yet that a content filter is not a containment boundary.

Anthropic’s own framing is the position to adopt: this is a convenience, and the boundary is the sandbox and the network. Treat an autonomous coding agent as untrusted code that runs on your behalf, box it accordingly, and the classifier becomes a nice-to-have rather than the only thing between an attacker’s web page and your credentials. The failure here was not really the classifier. It was anyone who believed the classifier was the wall.