Subagent-armed Monitor/background waiters die when the agent's turn ends — agent is never resumed

Summary

Background subagents (launched via the Agent tool) that arm a Monitor watcher — or a background Bash waiter — and then end their turn are never resumed when the watched condition fires. The watcher dies silently with the agent's turn; the agent waits forever on an event that cannot arrive. The parent session instead receives a task-notification stating the agent stopped "with no live background children," confirming the watcher was not kept alive/tracked on the agent's behalf.

Environment

• Claude Code 2.1.216, macOS (darwin 25.3.0), interactive session with async subagents
• Long-running work = local Verilator builds/sims (30–120+ min), launched by the subagent under nohup

Repro pattern (hit 5+ times in one orchestration session, across 4 distinct subagents)

1. Parent launches a background subagent via the Agent tool.
2. Subagent starts a long nohup job, then arms a Monitor (or a background Bash until-loop waiter) on the job's log/PID and ends its turn with "waiting for the monitor event."
3. The monitor/waiter does not survive the agent's stop. No event is ever delivered; the agent is never resumed.
4. Parent receives <task-notification> for the agent stopping with no live background children — even when the agent's final message explicitly says it just armed a waiter (e.g. "durable waiter armed to notify me").
5. The nohup job itself keeps running fine; only the wake-up is lost.

Notably, this happened even after the subagents' prompts were amended to describe the failure mode — agents naturally reach for "arm a watcher and wait," and the platform silently drops it.

Impact

Every long-running-validation workflow needs a manual workaround: the parent must run its own Bash run_in_background until-loop watcher on the subagent's job and SendMessage the agent back to life when the condition fires. That works, but it costs a parent round-trip per wait, requires the parent to discover the subagent's PID/log out-of-band, and is easy to get wrong (we also saw wedged agents earlier in the project when a session went idle and killed monitors — "idle sessions kill monitors" has become a standing ops lesson in our repo).

Ask (either would resolve it)

1. Bug-fix framing: background tasks/monitors armed by a subagent should count as live children of that subagent — keep the agent's task alive while they run, and resume the agent with the event when one fires (matching the documented "stops with no live background children" semantics).
2. Feature framing: if subagent-owned monitors are intentionally unsupported, make that explicit and fail loudly: reject/warn on Monitor + background-waiter calls from subagent context ("monitors do not survive agent turn end — report the PID/log to your parent instead"), so agents don't silently strand themselves.

A smaller quality-of-life addition: surface the subagent's armed-watcher state (or its absence) in the parent's task-notification, so orchestrators can distinguish "agent done" from "agent stranded waiting on a dead watcher" without parsing the agent's prose.