The invoking command was bash /tmp/.../test-lib-demo.sh. Nothing about that string looks destructive. The destructive part was inside the script — written by the same agent, moments earlier, in the same session.
What the report says
On August 21, 2026, a Claude Code user (WSL2/Ubuntu, Claude Opus 5, session running in auto mode with no confirmation prompts) filed anthropics/claude-code#88462 after a self-authored test script wiped their home directory.
During the session, the assistant wrote a bash helper function containing trap 'rm -rf "$_HT_HOME"' EXIT, meant to clean up a temp directory when the function's scope ended. Later in the same session it modified the function to reassign _HT_HOME="$HOME". A validation script then called the function twice: the first call armed the trap while _HT_HOME still pointed at the temp path; the second call reassigned _HT_HOME to $HOME. Bash evaluates a trap's variables at fire time, not arm time — so when the script exited, rm -rf ran against $HOME.
Claude Code's permission system checked only the literal command used to invoke the script. It never correlated that string with the destructive logic the assistant had written into the script's contents in the same session.
The wipe took the reporter's entire WSL2 home directory: environment configuration (hooks, agents, memory), roughly 1.4 GB of session transcripts, SSH keys, gh CLI authentication, and three in-flight conversations. Only partial recovery was possible from external backups. A pwd: error retrieving current directory: getcwd: cannot access parent directories error immediately following the deletion was treated as routine cleanup noise rather than recognized as a signal.
The part that raises this above a one-off bug
The issue explicitly frames this as the fifth report of the same underlying bug class — a permission system that inspects the invoking command string but not code the assistant just wrote and is about to execute — with four prior reports (#29082, #32938, #49129, #70687) each closed not_planned or duplicate rather than fixed. It's labeled area:permissions, area:sandbox, bug, data-loss, high-priority, platform:wsl, and remains open with no maintainer response at time of writing.
What it doesn't establish
One filed, verified report — not an independently reproduced failure mode with a known trigger recipe. The connection between this report and the four prior ones is the reporter's framing (via issue cross-references), not something we independently re-derived line by line.
Why it's scored 8.5/high, not critical
Full home-directory loss, including irreplaceable SSH keys and CLI auth, put this well above the corpus's medium-severity entries — but it's calibrated below 9.0+ critical incidents (STUPID-2026-0042 at 10, STUPID-2026-0088 at 9.2) because partial recovery from external backups was possible here, where those weren't recoverable at all.
Full record and sourcing: STUPID-2026-0094
This is one of 90+ severity-scored AI agent incidents documented at StupidLLM, an open incident database for AI coding agent failures — every entry marked with exactly how well-verified it is, including this one.
Top comments (0)