[Data Loss] Claude Code ran rm -rf on $HOME in auto mode — destructive code hidden inside a script the assistant wrote itself (5th report of this class)

Summary

On 2026-08-21, Claude Code executed rm -rf /home/leduc and destroyed my entire WSL2 home directory. No confirmation prompt was shown, in defaultMode: "auto".

The point of this report is not that the model wrote faulty code. It is that nothing in the permission chain could see it coming — and that this same class of incident has been reported here at least five times over six months, and closed each time (see "Prior reports" below).

What happened

1. The assistant wrote its own bash test helper containing:

``bash
trap 'rm -rf "$_HT_HOME"' EXIT
``

Single quotes: $_HT_HOME is expanded when the script exits, not when the trap is installed.

1. Minutes later, in the same session, it added an option to that same function which reassigns _HT_HOME="$HOME".

1. The validation script called the function twice. The first call armed the trap while the variable pointed at a temp dir; the second repointed it at $HOME. On exit, the trap read the current value.

1. The command submitted for permission checking was:

``
bash /tmp/.../test-lib-demo.sh
``

The actual product gap

bash <script> looks harmless — because it is, until you know what's inside the script. The destructive code lived in a file the assistant had written itself moments earlier in the same session. Nothing in the command line could reveal it.

The write path and the exec path are not correlated. A file authored by the assistant and then executed by the assistant bypasses inspection entirely, because inspection happens on the command string.

Two secondary points:

• No hard guard on $HOME. Nothing intercepted a recursive delete aimed at the user's home directory — arguably the single most predictable target of an accidental destructive command.
• The failure signal was swallowed. Output ended with pwd: error retrieving current directory: getcwd: cannot access parent directories — a direct symptom of the cwd having been destroyed. The assistant attributed it to normal temp-dir cleanup and continued for several turns before noticing. That specific error, immediately after running a cleanup script, deserves to be treated as an incident signal.

Environment

• Claude Code CLI on WSL2 (Ubuntu) under Windows
• Model: Opus 5 — claude-opus-5[1m]
• settings.json: "permissions": { "defaultMode": "auto" }
• Session ID: ce47a2ff-ee43-439c-854b-f033292541f4 (full transcript retained, contains every command in order, including the exact contents of the file that was written and then executed)

Generic reproduction shape

The assistant writes a script containing a cleanup trap on a variable → later reassigns that variable → then runs the script. None of those three steps is individually suspicious.

Impact

Permanent loss of several days of work: full environment configuration (hooks, agents, memory), ~1.4 GB of session transcripts, SSH keys, gh auth, and three in-flight conversations. Only part was reconstructed from external backups unrelated to Claude Code.

Prior reports of the same class

| Issue | Opened | Closed | Reason |
|---|---|---|---|
| #29082 — Claude Code executed rm -rf and deleted project files | 2026-02-26 | 2026-05-10 | not_planned |
| #32938 — Claude deleted 11h of inference output without permission | 2026-03-10 | 2026-05-01 | not_planned |
| #49129 — rm -rf permanently deleted ~1500 files | 2026-04-16 | 2026-05-24 | not_planned |
| #70687 — 3-year Unity project deleted | 2026-06-24 | 2026-06-28 | duplicate |
| #32637 — Cowork destroys user files | — | — | — |

Six months, five reports, no fix. This one is simply the most recent occurrence.

Suggested directions

1. Correlate write and exec. A script authored by the assistant in the current session and subsequently executed should be inspected at execution time, not only when written.
2. Hard-protect sensitive paths ($HOME, /, /etc) against recursive deletion, regardless of permission mode. This should not be defeasible by the model's own judgement about code the model itself just wrote.
3. Treat getcwd: cannot access parent directories as an incident signal, not a benign warning.

A detailed private report was also sent to usersafety@anthropic.com, and a support case is open regarding the billing side.