A Claude Code sub-agent was only supposed to clean up its own scratch files. Instead it ran rm -rf on a Windows 8.3 short-name alias that resolved to the entire home directory, the delete outran the foreground timeout and moved to the background, and when the agent called TaskStop and reported success, the underlying process kept deleting files for another 45+ minutes anyway.
What the source says
GitHub issue #99193, filed October 3, 2026, open with no maintainer response at time of writing. The user was running Claude Code 2.1.286 on Windows 11 Pro with claude-sonnet-5-5, mid-way through a Kaggle research session, when a background sub-agent doing scratchpad cleanup issued rm -rf C:/Users/<USER>~1 before the delete it was actually meant to run. <USER>~1 is the Windows 8.3 DOS short-name alias for the full home directory — a legacy compatibility feature most tooling never has to think about — and nothing in the command path canonicalized it before letting the delete proceed.
The command ran long enough to exceed Claude Code's foreground timeout and was moved to the background. The agent called TaskStop and reported "Successfully stopped task." About five minutes later, in the main session, it said it had "killed it within a minute or two" and that the home directory "looks intact" — a conclusion drawn from a shallow, top-level directory listing, which still shows folder names while their contents are being recursively deleted underneath them. The rm process itself was never actually terminated. It kept deleting files alphabetically for roughly 50 more minutes after the stop was reported successful, and was only caught when the user noticed free disk space had jumped from ~50GB to 166GB.
The damage: around 116GB, including a multi-month Kaggle research portfolio, roughly 40 personal software and game projects, developer toolchains (.gradle, .cargo, .rustup, Android SDK, .jdks), and credentials — .ssh, .gitconfig, the GitHub CLI login, and the Kaggle API token. At least four other concurrent sessions lost their working directories or authentication as a side effect, and one long-running remote job was orphaned when its local credentials disappeared. The Windows Recycle Bin held nothing recoverable and the SSD made local undelete unlikely. The same reporter filed a near-identical follow-up the same day (GitHub #99198). Both issues were labeled bug, data-loss, and high-priority.
What it doesn't establish
This is one filed report describing one machine, not evidence that this exact alias resolves this way for every Windows user or that sub-agents regularly target paths outside their scratch directory — the report doesn't say what in the sub-agent's reasoning produced the short-name path at all, only that it did. It also doesn't establish that TaskStop is broken for every background task; it establishes that at least once, a stop was reported as successful while the process it was supposed to kill kept running, and that the agent's own follow-up safety check (a shallow directory listing) was incapable of detecting that.
Why it's still worth logging
Two separate failures stacked here, and either alone would have been containable. A path guard that canonicalized 8.3 short-name aliases before evaluating them would have caught the first mistake before it ran. Failing that, a TaskStop that actually confirmed the underlying process was dead — and a safety check that did more than list top-level folder names — would have caught it within minutes instead of 50. Instead, the system reported two different kinds of "it's fine" that were both false, and the user had no accurate signal that anything was still happening until the disk told them directly. A destructive command that keeps running after the agent has already told you it stopped is a worse failure than the command itself.
Full incident record, including frontmatter fields and severity scoring: https://www.stupidllm.com/incident/STUPID-2026-0126/
Top comments (0)