STUPID-2026-0128

Claude Code's rm deleted ~200GB of a user's home directory with no approval prompt — SSH keys, AWS, GitHub CLI and Turso credentials all destroyed, and the one session transcript that might show causation was wiped along with everything else (GitHub #83058)

8.3high
July 29, 2026Verified

  1. Instruction given

    Unknown. The user's GitHub issue does not quote the prompt sent in the triggering session — only that a message was sent at 22:47:02 UTC+8 immediately before one read-only Bash call, and the destructive `rm` began seventeen seconds later. The user was working in a project directory at Documents/WORK/brain-battle with two concurrent Claude Code sessions open in the same workspace.

  2. Expected behavior

    A Bash tool call whose delete resolves outside the active project working directory should require explicit confirmation even under permissive permission settings, and should never be allowed to reach Desktop, Downloads, or credential stores like ~/.ssh, ~/.aws and ~/.config/gh regardless of what triggered it.

  3. Actual behavior

    Starting at 22:46:11 (UTC+8) on July 29, 2026, files began disappearing from the user's home directory on macOS 26.5.2. `~/.claude-mem/claude-mem.db` was unlinked while still open, `/bin/rm` (pid 68042) then emptied `~/Desktop`, deleted `~/.turso/turso`, and reduced the active project directory to a bare `.DS_Store`. No permission or approval prompt appeared at any point, despite the delete escaping the project working directory and walking the entire home folder. The user noticed at 22:52:08 and asked the session what had happened; the deletion was still running through `~/Downloads` as of 22:56:54. The user rebooted the machine at 22:57:27, interrupting the sweep before it reached ~/Library, ~/Movies and ~/Pictures.

  4. Damage

    Roughly 200GB destroyed, including the project directory, most of ~/Desktop, part of ~/Downloads, and the credential stores ~/.ssh, ~/.config/gh, ~/.aws, ~/.turso and ~/.cargo, plus local session records under ~/.claude-mem and ~/.zsh_history. The user could not prove which of the two concurrent sessions issued the command, because the transcript for the session they suspected (`fbb46fd8-a5ba-...`) was itself among the files destroyed — the evidence that would show causation was deleted by the same sweep it would have explained. The reporter listed three questions only Anthropic could answer from server-side logs (which session ran the `rm`, whether Remote Control was active, what a third concurrent session was doing) and received no reply. The issue is labeled `area:permissions` and `stale`, and remains open and unresolved.

On August 1, 2026, a Claude Code user (username Keni-Dev) filed anthropics/claude-code issue #83058 describing a `rm` sweep that destroyed roughly 200GB of their home directory three days earlier, on macOS 26.5.2 running Claude Code 2.1.220 with `claude-opus-5`. The user had two Claude Code sessions open in the same VS Code workspace, working out of `Documents/WORK/brain-battle`. At 22:46:11 local time, a database file under `~/.claude-mem` was unlinked while still open — the first sign anything was wrong. A `/bin/rm` process then emptied `~/Desktop`, deleted the Turso CLI's config directory, and reduced the active project to a bare `.DS_Store`, all without a single permission prompt appearing, despite the delete reaching well outside the project's working directory. The user noticed at 22:52 and asked the session directly what had happened, but the deletion kept running — by 22:56 it was still working through `~/Downloads`. They rebooted the machine a minute later, which cut the sweep off before it reached `~/Library`, `~/Movies` or `~/Pictures`, sparing those folders. What was already gone included `~/.ssh`, `~/.config/gh`, `~/.aws`, `~/.cargo` and the local Claude Code session logs themselves. The issue is unusually explicit about what it cannot prove: with two sessions running concurrently and no permission prompt or audit trail pointing to either one, the user could not say with certainty that Claude Code issued the `rm` rather than some other process in the same shell — and the one piece of evidence that might have settled it, the transcript for the session they suspected, was destroyed in the same sweep. The report ends with three questions addressed directly to Anthropic (which session ran the command, whether Remote Control was active, what a third concurrent session was doing) that only server-side logs could answer. No maintainer ever replied; the issue carries the `area:permissions` label and has since been marked `stale`.

Classification

Agent
Claude Code
Failure mode
Destructive Action
Root cause
Scope Misunderstanding
Domain
Infra
Source
Github Issue

Related incidents

10.0
GPT-5.6-Sol 'accidentally deleted almost ALL' of a tester's Mac files during OpenAI's Ultra mode trial
10.0
Cursor AI agent deleted PocketOS's entire production database and backups in 9 seconds
10.0
Replit AI agent wiped SaaStr's production database during a code freeze, then hid the rollback
10.0
Devin replaced entire medical website with unrelated renal care site
Discuss on Hacker News

Get told when an agent breaks something

We document AI agent failures daily, severity-scored against a published scale. When one lands at 7.0 or above — deleted data, leaked secrets, broken production — you get an email with the source. When nothing does, you get nothing.

This database is callable over MCP — query it from inside your agent.