[BUG] run_in_background tasks intermittently killed ~17-20s after start, seconds after the arming turn ends (terminal CLI, Linux — not idle-timeout timing)

Environment: Claude Code CLI v2.1.231, Linux 6.8.0-124-generic, terminal entrypoint (not Desktop), session running in a git worktree.

Symptom: Bash tool calls with run_in_background: true are intermittently killed by the client: the task-notification reports status killed ("Background command … was stopped") and \n[killed]\n is appended to the task output file. No timeout parameter was set, the user issued no stop, and the identical script runs 30+ minutes to completion at other times in the same session.

Timing evidence (from the session transcript JSONL; task ids are the harness-assigned background task ids):

| task | armed (UTC) | kill notification | Δ from arm | Δ from turn end |
|---|---|---|---|---|
| bcpsekz0z | 2026-08-18 05:25:45 | 05:26:04 | 19 s | 4.2 s |
| bonhyzzit | 2026-08-18 05:26:49 | 05:27:06 | 17 s | 0.5 s |
| b991t3gkq | 2026-08-18 15:01:52 | 15:02:13 | 20 s | 7.4 s |
| b51behwf8 | 2026-08-18 14:58:57 | 15:01:31 | 153 s | 2 m 18 s |

(plus two more kills on 2026-08-14; 7 total in one long session)

Ruled out by transcript forensics:

• User action: one kill burst (05:25–05:27 UTC) occurred with no human input for 2 h before and 7 h after.
• Session restart: the transcript has a single parentUuid chain root; the client never relaunched.
• Interrupts / slash commands / model switches: the kill windows contain no user records; the session's only interrupt record is days earlier.
• Script content / sandbox flag: the identical script (a gh pr checks poll loop with sleep 120) completed twice within the prior hour; other tasks with the same flags survived throughout.
• Documented default timeout: the 120 s foreground default does not match the 17–20 s deltas.

Pattern: every killed task was armed in the last tool call before its turn ended, and the kill landed 0.5–7 s after turn finalization (~17–20 s after arming). Kills come in bursts: a replacement task armed in the next (task-notification-triggered) turn was killed the same way ~17–20 s in. This looks like a race in turn-finalization cleanup sweeping up recently-armed background children.

Why this seems distinct from the known issues: #72851 and #68625 describe Desktop idle/lock teardown after 5–30 minutes of inactivity; #25188 (closed) covers session-end cleanup. This session was an active terminal CLI session (turns running continuously through the kill bursts), on Linux, with kills seconds — not minutes — after arming.

Impact: silent loss of watch tasks. When a workflow step (e.g. posting a CI trigger comment) lives inside such a task, the step is lost invisibly — silence is indistinguishable from "still running."

Workaround in use: the Monitor tool for watches; state-mutating commands never inside background tasks; avoiding arming a background task as the turn's final tool call.