Background task killed with status 'killed' though no TaskStop was issued for it (possible stop-routing race with a prior stop of a similar task)

Summary

A background task was terminated by the harness with status "killed" although no TaskStop was ever issued for it. The only TaskStop in the session targeted a different, earlier task with a nearly identical command line, issued ~20 seconds before the victim task was launched. The kill cost a multi-hour benchmark run (terminated ~1 second after its child process spawned) plus the investigation time to establish that neither the user nor the agent stopped it.

Environment

• Claude Code 2.1.206, Windows 11 Pro (10.0.26200)
• PowerShell tool, run_in_background: true tasks
• Times below are local, same session, 2026-07-09

Timeline

1. 14:39:10 — background task A launched: pwsh -NoProfile -File <repo>\scripts\test-perf.ps1 -TimeoutSeconds 7800 # broad-ok. The script spawns a test binary via Start-Process + WaitForExit, redirecting its output to a log.
2. ~14:39:30 — TaskStop(A) issued deliberately (to relaunch with a larger timeout). Returned success. A's process tree — the pwsh parent and its detached Start-Process child — terminated. Expected.
3. 14:39:52–55 — task B launched: same script, -TimeoutSeconds 14400 (near-identical command string), preceded in the same tool call by a Get-Process/Stop-Process sweep of stale test processes (which ran before B's pwsh started, so it cannot have killed B).
4. 14:39:55–56 — B's pwsh and its freshly-spawned Start-Process child terminated simultaneously: both output streams cut mid-line with no error text, and the script's own log lacks the end-stanza it writes on every surviving code path (file timestamps confirm all writes ceased at 14:39:55–56).
5. The harness later delivered B's task-notification with status: killed / "was stopped" — though the session transcript contains no TaskStop for B. The user confirmed they did not stop it either.

Fingerprint calibration (why this is a harness stop, not a crash)

Deliberately reproduced a real TaskStop against the same script shape: the kill reaches the whole tree including the detached Start-Process child, both streams cut with no error output, no script end-stanza — byte-for-byte the same signature as B's death. A crash or OS-level kill would have surfaced as status: failed with an exit code; killed is the harness's classification for stops it executes.

Repro attempts (both failed to reproduce — the bug did not recur)

1. Bare task: launch A (Start-Sleep 90; 'marker'), TaskStop(A), immediately launch B with the identical command line → B survived its full 90s and printed its marker.
2. Child-fidelity: parent pwsh script that Start-Process-spawns a child and WaitForExits (mirroring the victim's shape), same stop-then-launch sequence with near-identical command lines → B's parent and child both survived (child's marker file written), while the stop of A correctly killed A's child.

So "a TaskStop kills the next similar task" is not deterministically true — the incident looks like a race in stop routing/attribution (a stop matched against the newer task record with a near-identical command string created ~20s later, or a stop record applied twice).

Corroborating anomaly

A PreToolUse hook that had injected additionalContext on every comparable launch earlier that day (3 prior launches of the same script) injected nothing on either of the two 14:39 launches — hook processing behaved differently in exactly that window.

Expected

TaskStop terminates only its target task; a task with no issued stop is never terminated by the harness, and never classified killed.

Actual

A task with no issued stop was terminated ~1s into a multi-hour run and reported as killed.

Session reference (for internal correlation)

session_01BcYXyXiUK3hXQtt8T95CtL