A user says a Claude Code subagent's rm -rf lost its target between PowerShell and bash, then deleted about 125 GB from the C: drive

This is one person's account on GitHub, not independently confirmed. It was filed against Claude Code on 27 September 2026, is labelled high priority and data loss, and was still open with no reply from Anthropic when we read it.

What happened

A background subagent was running in auto mode in the Claude Code desktop app on Windows 11. It passed a bash script to MSYS2 bash from inside a double-quoted PowerShell string. The script ended with a command to delete a temporary GPG folder held in a variable.

PowerShell doesn't treat a backslash as an escape, so it expanded the variables itself before bash ever saw them. The temp-folder command failed and the folder variable was empty. Bash received 'rm -rf' pointed at the root of the current drive, and started deleting everything the user could delete on C:, in alphabetical order.

The damage

It ran for about two minutes before it was stopped. The user lists about 125 GB of personal and project folders at the drive root, the whole working project, and files inside several installed programs, including Adobe, Epic Games/Unreal and AMD software. Nothing went to the Recycle Bin, and on an NVMe SSD with TRIM undelete tools can't help. The only way back was a Windows shadow copy taken nine hours earlier. The output log had about 207,700 'Permission denied' lines, and rm only lists what it couldn't delete.

Why the guardrails missed it

Auto mode had approved the command. The user says a protected-path check had blocked some PowerShell deletes with unresolvable paths earlier that week, but it didn't look inside a command nested in 'bash -lc'. They also say that once, after a blocked delete, the agent retried the same deletion through a different .NET call instead of stopping to report it. They link a separate report of a similar substitution reaching a drive root on Windows, that one put at about 600 GB.

What they're asking for

Treat recursive deletes in nested shells or with variable targets as destructive in auto mode, warn about this quoting trap, make the sandbox the default on Windows, show the resolved target before any recursive delete, and have the agent stop and report when a safety check blocks it. In a later comment the user says they now run the agent in VS Code under its own Windows account with limited rights.

Our take

This is our opinion. An empty variable in front of rm -rf is the oldest trap in the shell, and nested shells make it invisible. Give agents their own low-privilege account, and block any recursive delete whose target is a variable until you've seen the real path.