A Claude subagent's empty variable turned rsync --delete on the whole disk, and stopping it didn't stop it

This is one person's account on GitHub, not independently confirmed. It landed in Claude Code's public issue tracker in the early hours of 14 November, and it is the kind of report that makes every overnight agent run look a little less relaxing.

What happened

The user says they were running a multi-agent session in the Claude desktop app's Code tab on Windows 11, with WSL2 Ubuntu and a data drive mounted inside Linux. They had asked the agent to keep working overnight without waiting for approvals. One subagent wanted a Linux copy of a project folder, so it sent a one-line script through wsl.exe that set a variable for the destination folder and then ran rsync -a --delete into it.

The variable never made it. The report says the command line was expanded by another shell layer on the way through wsl.exe, so the destination arrived as an empty string. A set -u safety flag inside the script didn't help, because the damage was done before that script even started. The command that actually ran was, in effect, rsync with --delete pointed at /.

How it went wrong

rsync with --delete makes the destination match the source, deleting anything that isn't in the source. Pointed at the root of the filesystem, it started deleting everything the user's account was allowed to touch, including /tmp and folders on the Windows data drive mounted under /mnt/d. Files deleted through WSL skip the Windows Recycle Bin.

Then two more things went wrong. The coordinating agent stopped the subagent's task, but that only ended wsl.exe on the Windows side. Inside Linux, rsync kept going for about two more minutes until it was killed by hand. And the subagent's first damage report said the user's documents folder had not been touched. It had judged that from the absence of error lines, but rsync doesn't print successful deletions. The real scope only turned up hours later.

The damage

The user lists permanent loss of several folders of business documents, design files, analysis videos and months of backups. They say recovery is being tried with a file recovery tool, and anything overwritten since may be gone. As of writing the issue was open with a data-loss label, and there was no public response from Anthropic in it.

Our take

Every link in this chain is a known trap: a variable as the target of a destructive command, a command passed through two shells, an unattended mode with no approvals, and a stop button that didn't reach the child process. Guard every delete target with a hard check that refuses empty or root paths, run multi-line work as a script file inside WSL, keep important drives off an unattended agent's map entirely, and make sure your kill switch kills the whole process tree. Backups the agent can't reach are the only thing that really saves you.