Runaway rm -rf: timeout auto-backgrounding kept a destructive command running, and TaskStop did not kill the child process (Windows)

Summary

A subagent (spawned via the Agent tool) ran rm -rf "\\" in Git Bash on Windows, intending to delete a stray directory literally named \ inside the repo. MSYS path translation resolved the bare backslash to the root of the current drive, and the command recursively deleted C:\ contents in alphabetical order for ~7 minutes before being killed manually. Several top-level directories under C:\dev were destroyed (recovered afterwards via a VSS shadow copy). The agent error itself is on the model, but the blast radius was multiplied by two harness behaviors that seem worth fixing.

Environment

• Claude Code CLI on Windows 11 Home (10.0.26200), PowerShell primary + Git Bash tool
• Model: claude-fable-5 (main session and subagent)
• The destructive command ran inside a background subagent via the Bash tool

Harness issues

1. Commands that exceed the Bash timeout are backgrounded and keep running unsupervised

The compound command was rm -rf "\\" 2>/dev/null; <multi-minute render loop>. It exceeded the 2-minute tool timeout and was moved to a background task. The destructive part kept executing with no output visible to anyone. A destructive command silently promoted from "foreground, watched" to "background, unwatched" changes its risk profile a lot; a timeout-kill (or at least a prompt) may be safer than auto-backgrounding.

2. TaskStop killed the shell but not the child process

When the agent realized the problem and called TaskStop on the background task, the tool reported success, but the underlying rm.exe child process survived and kept deleting for roughly 5 more minutes until it was killed manually by PID. On Windows, stopping a task apparently terminates the shell without terminating its process tree. TaskStop should kill the whole process tree (e.g. taskkill /T semantics or Job Objects).

3. (Defense-in-depth suggestion) No built-in guard for catastrophic delete targets

rm -rf "\\" — and cousins like rm -rf /, rm -rf C:\ — sailed through with no friction. The "\\" → drive-root resolution via MSYS path mangling is obscure enough that a model plausibly won't anticipate it. A small built-in denylist for recursive deletes targeting drive roots / / / ~ (we now run one as a PreToolUse hook) would be cheap insurance, especially since these forms can evade permission-rule pattern matching (the quoted backslash form does not look like rm -rf /*).

What the model did wrong (for completeness)

Ran a recursive delete on an argument it never verified (an ls "\\" first would have listed C:\ and revealed the trap), suppressed stderr (2>/dev/null) which hid the error flood, and bundled the delete with a long-running loop that guaranteed the timeout/backgrounding.

Impact and recovery

C:\dev (multiple projects, some with no remote backup) was deleted; rm bypasses the Recycle Bin. Recovery succeeded via a same-day Volume Shadow Copy plus GitHub remotes; one directory created after the snapshot was permanently lost. Everything alphabetically after dev on C:\ survived because the process was killed mid-walk.