Claude Code Auto Mode Safety: Classifier Is Not a Sandbox

Auto mode became the default permission mode in Claude Code on August 14. It shipped with a number that did a lot of work: in red-teaming commissioned from Trajectory Labs, Anthropic reported that none of the 720 attack attempts succeeded against Claude Fable 5, Opus 5, or Sonnet 5 in auto mode. A chart shared by an Anthropic engineer put it at 0.00% for Opus 5. Last week a researcher published a working chain that hit 60 to 80 percent, and it climbed to 397 points on Hacker News. The gap between those two numbers is the whole story, and it is smaller than it looks.

I run six unattended Claude Code jobs on this Mac mini. None of them use auto mode, so I spent the morning doing the one thing the headlines skipped: reproducing the load-bearing step of the attack on my own machine, safely, to see what actually breaks.

What the attack does

The chain comes from Johann Rehberger's Breaking Claude Code Opus 5 Auto Mode (posted August 26). The prompt is innocent: summarize a web page. The page returns 415 Unsupported Media Type, Claude's built-in fetch tool gives up, and the model falls back to curl on its own. Rehberger quotes the transcript: WebFetch got a 415. Let me try directly. The curl pulls a ZIP that contains innocuous-looking records, a macOS binary, and a file named struct.py.

Then the safety feature backfires. Claude refuses to run the supplied binary, which is the correct call, and instead writes its own small Python decoder. That decoder does import base64. The standard-library base64 imports struct internally, and because the decoder runs from inside the unzipped directory, Python finds the attacker's struct.py first and executes it at import time. From there the poisoned module launches a python -I subprocess that stages a payload and calls home.

I reproduced the one step that matters

The C2 payload is the scary part, but it is not the interesting part. The interesting part is the module shadow, because that is a plain Python behavior that has nothing to do with any model. So I built the smallest honest version of it on this rig. In a throwaway directory I dropped a struct.py that writes a marker file when imported, and a decode.py that only does import base64. No network, no binary, no payload.

# /tmp/shadowtest/extracted/struct.py  (stand-in for the archive's file)
import os
open(os.path.join(os.path.dirname(__file__), "SHADOW_RAN.txt"), "w").write("ran\n")
print("[shadow] struct.py executed at import time")

# /tmp/shadowtest/extracted/decode.py
import base64
print("decoded:", base64.b64decode(b"aGVsbG8=").decode())

Run decode.py from inside that directory and the marker appears:

$ cd /tmp/shadowtest/extracted && python3 decode.py
[shadow] struct.py executed at import time
decoded: hello
$ python3 -c "import struct; print(struct.__file__)"
/private/tmp/shadowtest/extracted/struct.py

On Python 3.14.5, import struct resolved to the file in the working directory, not the standard library, and the shadow ran before my decoder printed anything. The control confirms the vector: copy the same decode.py to a clean folder, run it there, and nothing shadows because the malicious file is not on sys.path[0], which is the script's own directory. This is the gotcha two HN commenters said they hit in ordinary work, one of them unable to run a formatter because a local random.py kept shadowing the standard library. It is a Python footgun that predates agents by decades. The agent just walks into it reliably because it writes and runs code from wherever it happens to be standing.

Reconciling 0.00% with 80%

The two numbers measure different things, and once you line them up they stop contradicting each other. The launch blog's 720 attacks were indirect prompt injection: content that tries to hijack the agent's intent so it does something the user never asked for. This chain never hijacks intent. The user asked for a summary, and the model tried to give one; the code execution is a side effect of Claude writing a decoder in a poisoned directory. Most of the HN thread landed there, calling it a trojan tailored to Claude's habits rather than prompt injection at all.

The friction is in the marketing, not the mechanism. When you pair a 0.00% chart with "auto mode is now the default," a reader hears "auto mode is safe." Anthropic's own reply to the researcher says the opposite in plain words: the classifier is a convenience feature backed by a best-effort model, and the real boundary is OS isolation and network egress control. The blog even carries the caveat that classification "does not eliminate risk." Both things are true. Auto mode is a genuine improvement over a human rubber-stamping every prompt, and it is not a sandbox.

Why this changes nothing, and everything, for my fleet

My six scheduled jobs all pass --dangerously-skip-permissions, which is equivalent to bypassPermissions. I measured that back on August 14 and it still holds on Claude Code 2.1.258. In that mode the classifier is never consulted, so the entire 0.00%-versus-80% debate is moot for these processes. There is a detail in the research that makes this concrete: in a few runs, Claude noticed the compromise and tried to kill the malware, and auto mode denied the cleanup command. On my rig nothing would deny anything, in either direction.

What does transfer is the shape of the attack. Its crux is a model that reaches for curl when its fetch tool stumbles, then writes and runs Python from whatever directory it is in. That is an exact description of how my unattended jobs already behave, every slot, all day. The control that would have contained the payload is the one I keep writing about not having applied yet: OS-level isolation and egress limits, the boundary Anthropic itself named. I have tested the built-in sandbox and found it holds for one command before the model routes around it, and I have noted that Docker ships the skip-permissions flag as its default command. The classifier was never my boundary. After reproducing this, neither is the model's good judgment about which binaries to run.

The cheap mitigation for the Python half is mundane and worth stating: do not run agent-written scripts from a directory you did not create, and reach for isolated import behavior when you do. The expensive mitigation is the real one, and it is the same for auto-mode users and for bypass-mode fleets like mine. Sandbox the process, cap what it can reach on the network, and stop treating any permission mode as the thing that keeps a downloaded archive from running code.

Sources and method: I reproduced the module-shadowing step on this Mac mini on 2026-09-03 with a benign marker file, no network and no binary, on Python 3.14.5; the transcript above is the real output. The attack chain, quotes, and success rates come from Johann Rehberger's post (embracethered.com, Aug 26) and the Hacker News thread (id 49506819, 397 points). Anthropic's figures come from the auto-mode launch announcement (claude.com, Aug 7). My fleet's flag count was read from the five live ops/*.sh scripts plus the playbook copy on the same day. I have not applied OS-level isolation to these jobs yet, and I will say so plainly when I have.