[BUG] Deliberately backgrounded long-lived tasks armed by subagents are killed early with no notification to the owning subagent

What's Wrong?

Long-lived background Bash tasks that a subagent deliberately arms as watchdogs/watchers (run_in_background: true, expected lifetime 20–60 min) are frequently killed by the harness well before completing, with no notification to the owning agent. We logged dozens of instances in one week; the owning agent's next wake simply never comes, and inspection shows the task's output file stopped mid-stream with a [killed] marker the agent was never told about.

This is the aggravator for the other completion-delivery gaps: the watcher is precisely the mitigation an agent arms so it cannot sleep forever — when it is reaped silently, nothing wakes anyone.

What Should Happen?

A background task armed by a live, waiting subagent should either be allowed to run to its natural exit, or — if the harness must reap it — the owning agent should receive the killed notification so it can re-arm.

Steps to Reproduce

1. Spawn a background subagent whose prompt is: "Start this background Bash task and record its id: a script that polls a file's mtime every 60 s and exits when the file is older than 45 minutes. Then end your turn and wait; if you are woken by anything, log the reason to /tmp/wake.log and wait again."
2. Let the session continue with other activity across several turns.
3. Observe: the armed task is frequently killed within minutes–tens-of-minutes (its output file ends with [killed]), no notification reaches the owning subagent, and /tmp/wake.log shows no wake.

Context (shared setup for this report)

We run deep background-subagent trees (session root → coordinator agent → slice agents → task agents, all general-purpose, fork mode on, interactive CLI session). Since all Agent spawns became asynchronous, "end the turn with live background tasks" is the wait primitive: the harness re-invokes the parent when a child completes. That contract holds for fresh spawns — this report is about one specific case where it breaks. Observed across ~9 long autonomous runs on Claude Code 2.1.234–2.1.238 (Linux/Fedora, Anthropic API).

Error Messages/Logs

(see Steps to Reproduce; key strings quoted inline)

Claude Model

Not sure / Multiple models (sonnet + opus subagents)

Is this a regression?

I don't know (observed on every version we ran: 2.1.234 → 2.1.238)

Claude Code Version

2.1.238 (Claude Code)

Platform

Anthropic API

OS

Linux (Fedora 44)

---
Related (distinct bugs in the same subsystem, filed separately per the single-bug rule): #89042, #89043, #89044. Together they make completion delivery unreliable for anything except fresh never-resumed spawns; field evidence: ~4–5 h of stalls across 9 multi-agent runs in one week.