[BUG] TaskStop does not kill the process tree — orphaned `rm -rf /c` deleted user data for 20 minutes after stop

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

TITLE (paste into the issue title field)

[BUG] TaskStop leaves the child process running — orphaned rm kept deleting user data for ~20 min after the tool reported it stopped

---

BODY (paste into the issue body field, starting below this line)

Summary

TaskStop terminated only the shell wrapper process, not the process tree. The actual rm child process was orphaned and continued deleting for approximately 20 minutes after the tool reported the task as stopped. Because both the agent and I believed the operation had been halted, nobody intervened during that window.

The command that was running was a destructive one the agent should not have issued (rm -rf /c, which resolves to the entire C: drive in Git Bash). That is a separate problem, and I list it under hardening suggestions below. But the reason this became data loss rather than a near-miss is the orphaned process: the agent detected the problem within ~3 minutes and called TaskStop, and the deletion still ran for another ~20 minutes.

Environment

• Claude Code 2.1.222 at the time of the incident (latest at time of filing: <FILL IN>)
• Windows, launched from the Claude Desktop app "Code" tab
• Model: claude-opus-5, effort: high
• permissionMode: acceptEdits
• Git worktree mode enabled
• CLI session ID: 145956ba-4272-4038-a689-1a2c91357349
• Terminal/Shell: no standalone terminal — the session ran inside the Claude

Desktop app "Code" tab. The Bash tool is backed by Git Bash / MSYS2; the
PowerShell tool was also used in the same session. (Selected "Other" in the
dropdown, as none of the listed terminals applies.)

## Actual behaviour

Only the bash wrapper was terminated. The rm process (PID 30172) was orphaned and kept running for approximately 20 minutes, until it was manually killed with Stop-Process -Id 30172 -Force.

A compounding effect: during those 20 minutes the agent inspected the filesystem to assess damage and twice reported "No damage" — it was reading files the deletion had not reached yet and interpreting them as safe. So the stale TaskStop success signal did not just fail to stop the work; it actively produced false reassurance.

Timeline (JST, 2026-08-09)

| Time | Event |
|---|---|
| ~13:40 | Agent runs rm -rf /c 2>/dev/null via the Bash tool |
| ~13:43 | Agent calls TaskStop. Only the bash wrapper dies; rm (PID 30172) is orphaned and continues |
| 13:47:52 | Agent reports "No damage" to me (incorrect — deletion still running) |
| 13:55:45 | Agent revises to "only C:\c was deleted" (still incorrect) |
| 13:57:12 | du -sh Simulation_Run returns 61M — directory still present |
| 13:59:15 | PowerShell Copy-Item fails: the same source no longer exists |
| 14:00:38 | Agent finds rm PID 30172 still running, ~20 minutes elapsed since TaskStop |
| 14:00:40 | Stop-Process -Id 30172 -Force — deletion finally stops |
| 14:06:49 | Project directory confirmed to contain only .claude; .git gone |
| 14:08:44 | Confirmed: no volume shadow copies, no restore points on the volume |
| 14:09:41 | Agent reports the data destruction to me |

Verbatim from the agent's own message at 14:00:38:

rm PID 30172 is still running — TaskStop killed the bash wrapper but not the detached child. It's been deleting for ~20 minutes.

Impact

Roughly 20 minutes of recursive deletion under C:\Users\<user>, alphabetically from .claude through Documents, stopping partway through the Documents subtree.

Destroyed: ~/.claude (all Claude Code transcripts and prompt history), Desktop, Downloads, Contacts, several application settings directories, and most of Documents — including an entire project directory with its .git, and a second project that existed only locally.

Permanently lost: two unpushed commits, untracked working files, several hundred MB of gitignored simulation output, one local-only repository, and all Claude Code session history except the single session that was actively running (which is the only reason this report can be written at all).

MSYS2's rm bypasses the Recycle Bin, and there were no shadow copies or restore points on the volume, so nothing was recoverable through Windows. Code was restored from the GitHub remote; everything outside version control was not.

The bug

TaskStop must terminate the entire process group / job object, not just the shell wrapper.

On Windows this means assigning the spawned shell and its descendants to a Job Object and terminating the job. On POSIX, signalling the process group rather than the direct child.

Until that holds, TaskStop returning success is not a safe signal, and any subsequent state the agent observes may be mid-mutation.

Additional hardening suggestions

These are secondary to the bug above. I am happy to file any of them as separate issues if that is preferred.

1. Block deletions targeting drive roots and mount points by default, regardless of permission mode — /c, /d, /, ~, $HOME. Git Bash drive mount points on Windows are a particularly sharp edge: /c looks like a relative-ish path and is the whole system drive.
2. Refuse or warn when error suppression is combined with a destructive command (2>/dev/null, -ErrorAction SilentlyContinue). Here it hid every permission error and made the blast radius unobservable.
3. Verify a task's process has actually exited before reporting on its outcome. A damage assessment run against a filesystem that is still being mutated is worse than no assessment.
4. Protect ~/.claude from agent-initiated deletion. The transcript store is a single point of failure; here the agent destroyed the record of its own incident, which made post-hoc analysis considerably harder.

Related issues

Similar orphaned-process reports exist, but none covers TaskStop returning success while the child keeps running, or the data-loss consequence:

• #23154 — Subagents can't run TaskStop, can orphan their own Bash tasks
• #32183 — Windows: /exit does not terminate child bash.exe processes
• #43944 — Background processes started by Bash tool are not cleaned up on session exit

Evidence

The full session transcript for the incident window (77 records, 13:46:52–14:09:41 JST) survived and is preserved. It contains the TaskStop call, the process listing showing PID 30172 alive, and the agent's own analysis.

I have not attached it here because it contains file paths, company identifiers, and commit messages from confidential work. I am happy to provide it privately to Anthropic on request.

What Should Happen?

TaskStop should terminate the entire process tree for the task, not just the
shell wrapper. After TaskStop returns success, no work initiated by that task
should still be executing.

On Windows this means assigning the spawned shell and its descendants to a Job
Object and terminating the job. On POSIX, signalling the process group rather
than the direct child.

Concretely, in this incident: the rm process (PID 30172) should have died when
TaskStop was called at ~13:43. Instead it kept deleting for another ~20
minutes. Had it stopped there, the damage would have been limited to a couple of
directories rather than most of the user profile.

Secondarily, a successful TaskStop should be a signal the agent can rely on.
Any filesystem state the agent inspects afterwards should be settled, not
mid-mutation — otherwise a damage assessment reads not-yet-deleted files as
safe, which is exactly what happened here.

Error Messages/Logs

Steps to Reproduce

1. On Windows, have the agent run a long-running destructive command through the

Bash tool (Git Bash). In this incident: rm -rf /c 2>/dev/null.

1. The command appears to hang.
2. The agent calls TaskStop on that task.
3. TaskStop returns success.
4. Inspect running processes — the rm child process is still alive and still

doing work.

Note: I have not attempted to reproduce this deliberately, for obvious reasons.
The above is reconstructed from the real session transcript, which recorded the
TaskStop call and, ~20 minutes later, a process listing showing PID 30172
still running.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.222

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_

for m in model-a model-b model-c; do
  timeout 5400 python -m some_long_running_job --model "$m"
done

alive=$(powershell -NoProfile -Command \
  "@(Get-CimInstance Win32_Process -Filter \"Name like 'python%'\" | Where-Object { \$_.CommandLine -like '*some_long_running_job*' }).Count" \
  2>/dev/null | tr -d '\r ')
if [ "${alive:-0}" != "0" ]; then
  echo "ABORT: ${alive} job process(es) already running"; exit 1
fi

{"message":"Successfully stopped task: bcntp5fq4 (cd \"…/scratchpad\" && cat > runner.sh <<'EOF' …)","task_id":"bcntp5fq4","task_type":"local_bash", …}

Get-CimInstance Win32_Process -Filter "Name='bash.exe' OR Name='sleep.exe'" |
  Where-Object { $_.CommandLine -match '<script name>' } |
  ForEach-Object { Stop-Process -Id $_.ProcessId -Force }