[BUG] Recursive rm deleted ~200 GB of home directory — no approval prompt for a delete outside the project cwd

Status Open

Reported on v2.1.220

Maintainer reply None cached

Activity 0 comments · opened Aug 1, 2026

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report
[x] I am using the latest version of Claude Code

What's Wrong?

During an active Claude Code session, a recursive /bin/rm deleted the contents of my home
directory — roughly 200 GB across ~/Desktop, ~/Documents, and part of ~/Downloads. It ran
for about eleven minutes and was still working when I rebooted, which is the only reason anything
survived.

No approval prompt appeared at any point, despite the delete escaping the project working
directory (Documents/WORK/brain-battle) and walking the entire home folder — including every
credential store: ~/.ssh, ~/.config/gh, ~/.aws, ~/.turso, ~/.cargo, ~/.local/bin.

I want to be upfront: I cannot prove Claude Code issued the command. What I can prove is that
/bin/rm ran from a shell inside VS Code, which is where my Claude Code session was running. The
evidence that would settle it was destroyed by the deletion itself. I am filing this for the
product defect above, and because there is a server-side check only Anthropic can run.

What Should Happen?

A Bash tool call whose delete resolves outside the project working directory should require
explicit confirmation, even under permissive permission settings. A delete inside the project is
ordinary work; one that escapes into $HOME is categorically different and should not proceed
silently.

Error Messages/Logs

macOS logged the deleting process requesting Desktop access at the exact second ~/Desktop was
emptied:

22:47:56  tccd  AUTHREQ_ATTRIBUTION: msgID=1364.72
  service     = kTCCServiceSystemPolicyDesktopFolder
  accessing   = {identifier=com.apple.rm, pid=68042, binary_path=/bin/rm}
  responsible = {identifier=com.microsoft.VSCode, pid=16001,
                 path=/Applications/Visual Studio Code.app/Contents/MacOS/Code}

Nine seconds earlier the kernel blocked the same PID at the Trash:

22:47:47  System Policy: rm(68042) deny(1) file-read-data /Users/keni/.Trash

accessing is the process doing the work. responsible is what macOS holds accountable — a
shell inside VS Code.

An unexplained SDK-driven session fired inside the same window and left no transcript on disk:

~/.claude/debug/27159862-91ee-4ae7-b6b3-769de495dd16.txt
  14:48:26.529Z  [Query.streamInput] Finished processing 5 messages from input stream
  14:48:26.530Z  [Query] Calling transport.endInput() to close stdin to CLI process

Steps to Reproduce

I cannot reproduce this, and I want to be honest about that rather than invent a repro. It
was a single unrepeatable incident. What I can give is the exact reconstructed sequence, all
times UTC+8 on 2026-07-29:

Claude Code session d84cf2f4-7df9-4e5c-8657-144347d5348e running in

Documents/WORK/brain-battle, VS Code integrated terminal.

A second session fbb46fd8-a5ba-4d70-8a0c-9ccf1b453b90 running concurrently in the same

workspace with background tasks.

22:46:11 — ~/.claude-mem/claude-mem.db unlinked while open. First casualty.
22:47:02 — I send a prompt. 22:47:30 — session runs one read-only Bash call.
22:47:47 — /bin/rm (pid 68042) blocked by the kernel at ~/.Trash.
22:47:56 — same PID requests Desktop access; ~/Desktop is emptied.
22:48:15 — ~/.turso/turso reported missing. It had worked 28 seconds earlier.
22:49–22:51 — project directory reduced to a bare .DS_Store.
22:52:08 — I notice and ask the session what happened.
22:56:54 — still deleting, now in ~/Downloads.
22:57:27 — I reboot, which interrupts it.

The delete walked the home folder in directory order —
.cache → .claude → .claude-mem → … → Desktop → Documents → Downloads — and the reboot killed it
mid-Downloads. Everything alphabetically after that (Library, Movies, Pictures) was
untouched.

At no point was I shown a permission prompt.

Claude Model

claude-opus-5

Is this a regression?

Not sure — I have no prior occurrence to compare against.

Last Working Version

N/A

Claude Code Version

2.1.220

Platform

Claude subscription (OAuth account, not a direct API key)

Operating System

macOS 26.5.2 (build 25F84), Apple Silicon

Terminal/Shell

VS Code integrated terminal, zsh

Additional Information

What the surviving transcript shows

Session d84cf2f4-7df9-4e5c-8657-144347d5348e is intact. It contains six Bash calls, all
read-only — database counts, a config fetch, then post-incident investigation. None is a
delete. On its face this session is clean.

The gap

Session fbb46fd8-a5ba-4d70-8a0c-9ccf1b453b90's transcript was destroyed by the sweep, along
with ~/.zsh_history (truncated to 1 line), ~/.claude/history.jsonl (truncated to 3 entries),
and /private/tmp/claude-501/-Users-keni-Documents-WORK-brain-battle/.

So the responsible application and the mechanism are both established, but which session or typed
command issued the rm cannot be determined locally — the record deleted itself.

I also checked GitHub Copilot chat sessions in the same workspace: every rm -rf in them is from
March–May and correctly path-scoped. None were modified on 29 July.

Remote Control

I habitually leave Claude Code Remote Control enabled. I was not driving anything remotely at
the time; that session was idle. I raise it because a Remote-Control-driven session executes
locally while the prompt originates elsewhere, which would produce exactly this picture.

I could not verify it locally: there is no remoteControlEnabled key in ~/.claude.json, only
remoteControlUpsellSeenCount: 1, which records the feature being shown to me rather than being
active. The .claude.json backups from 29 July have rotated out, and ~/.claude/sessions/*.json
is keyed by PID so only current sessions survive.

Three questions answerable only on your side

Incident window 2026-07-29 14:46–14:57 UTC. Account, machine and user IDs available
privately.

Did session fbb46fd8-a5ba-4d70-8a0c-9ccf1b453b90 issue a recursive rm?
Was Remote Control active for this machine in that window, and if so what prompts were

delivered, from which client?

What was session 27159862-91ee-4ae7-b6b3-769de495dd16?

I would genuinely like the answer either way — including if it clears Claude Code entirely,
because then I need to look elsewhere.

A related durability problem

Session transcripts, history.jsonl and background-task output all live under ~. A destructive
event in $HOME therefore erases its own audit trail — which is precisely why this report cannot
be conclusive. An immutable or out-of-tree copy would have made it so. Happy to split this into
its own issue if preferred.

Recovery note, for anyone who finds this later

No undelete tool works on an Apple Silicon internal SSD — APFS with TRIM discards freed blocks
within seconds, and the drive cannot be attached raw to another machine. I recovered ~2,000 files
anyway, entirely from application-level backups that lived in ~/Library and were never reached:

VS Code / Antigravity Local History (~/Library/Application Support/*/User/History) — 1,256 files
An Istanbul HTML coverage report in ~/Downloads — 822 files; coverage HTML embeds the

complete source of every covered file

Claude Code's own ~/.claude/file-history, plus full file bodies preserved inside Write

tool calls in the surviving transcript

That last one is worth knowing: Claude Code's file-history and transcripts are a genuine recovery
source after local data loss. They are also, per above, stored where local data loss can reach them.

View original on GitHub ↗