Symptom: a subagent that ends its turn with a pending Monitor(persistent: true) is never revived when that monitor emits an event. The monitor's own command runs to completion normally (verified in the 2026-08-23 repro: the loop exited after the condition became true); the completed subagent is simply never woken, and whatever it promised to report dies unread. Only the top-level session receives task events reliably.
This makes the "arm a watch, end the turn, report when it fires" pattern — which the Monitor tool description actively encourages — silently unusable inside a subagent.
Environment
- Claude Code 2.1.258 (interactive CLI, not stream-json), macOS Darwin 25.6.0, Apple M2
- Originally observed on 2.1.220; re-verified on 2.1.258 before filing
Minimal repro
Top-level session spawns one depth-1 subagent whose entire prompt is:
Monitor with persistent: true and
command: until [ -f /tmp/repro/flag ]; do sleep 2; done; echo MONITOR_FIREDdate > /tmp/repro/armed.txt- End the turn immediately with the word
ARMED (do not poll, do not wait)
- If later revived by the monitor event:
date > /tmp/repro/revived.txt, end turn with REVIVED
The parent waits for armed.txt, then creates /tmp/repro/flag.
Result on 2.1.258: armed.txt written, flag created 5s later, revived.txt never written, no further turn from the subagent within 180s. The subagent's last and only output was ARMED.
Measurements
| when |
version |
depth |
outcome |
| 2026-08-22 (production incident) |
2.1.220 |
2 |
not revived |
| 2026-08-23 (controlled repro) |
2.1.220 |
2 |
not revived |
| 2026-08-23 (controlled, flag file) |
2.1.220 |
1 |
not revived |
| 2026-09-18 (controlled, flag file) |
2.1.258 |
1 |
not revived |
The single revival ever observed (the 2026-08-22 incident, depth 3) is the anomaly: that agent had been resumed via SendMessage in between, which appears to have re-registered it.
What does work (for contrast)
- A background agent's completion broadcast reaches the top-level session reliably at any depth — a depth-3 grandchild's final report arrived at the main session in the same second, without passing through its already-completed parents.
SendMessage addressed by agent id revives a completed agent ("was stopped (completed); resumed it"). Addressed by agent type it fails with "no reachable agent by that name".- So the wake path exists and works when driven externally. It is specifically the agent's own pending Monitor event that does not drive it.
Same failure via backgrounded Bash
A subagent's own Bash(run_in_background: true) task is no better. 2026-08-27: a CI-watching subagent backgrounded its wait because the 600s foreground cap would have been exceeded, then ended its turn. The child completed ~20 minutes later; the subagent was never revived. The verdict was only recovered because the top-level session had independently armed its own watcher on the same file.
Impact
In the original incident a correct CI verdict sat unread for 21 minutes: the subagent had reported "watch armed, I'll report when it fires", and nothing was ever going to fire it. The promise reads as a valid contract to both the agent and the person reading the transcript, and it is backed by nothing.
The workaround is to forbid the pattern outright in subagents — a watching subagent must hold its turn open with a foreground Bash until-loop (re-run on exit 124), and the caller must additionally own a deadline and do one cheap direct read if the silence exceeds it. That works, but it means a subagent cannot absorb a wait longer than its foreground budget without the caller duplicating the watch.
Possibly related
Ask
Either:
- Deliver a subagent's own pending task events to it and resume it, the same way
SendMessage by agent id already resumes a completed agent; or
- If Monitor-then-exit is intentionally a top-level-only pattern, say so in the
Monitor tool description and make the call fail loudly (or warn) when a subagent arms a persistent monitor it will never see fire.
Silent non-delivery is the worst of the three, because the agent confidently reports that the watch is armed.
Symptom: a subagent that ends its turn with a pending
Monitor(persistent: true)is never revived when that monitor emits an event. The monitor's own command runs to completion normally (verified in the 2026-08-23 repro: the loop exited after the condition became true); the completed subagent is simply never woken, and whatever it promised to report dies unread. Only the top-level session receives task events reliably.This makes the "arm a watch, end the turn, report when it fires" pattern — which the Monitor tool description actively encourages — silently unusable inside a subagent.
Environment
Minimal repro
Top-level session spawns one depth-1 subagent whose entire prompt is:
Monitorwithpersistent: trueandcommand: until [ -f /tmp/repro/flag ]; do sleep 2; done; echo MONITOR_FIREDdate > /tmp/repro/armed.txtARMED(do not poll, do not wait)date > /tmp/repro/revived.txt, end turn withREVIVEDThe parent waits for
armed.txt, then creates/tmp/repro/flag.Result on 2.1.258:
armed.txtwritten, flag created 5s later,revived.txtnever written, no further turn from the subagent within 180s. The subagent's last and only output wasARMED.Measurements
The single revival ever observed (the 2026-08-22 incident, depth 3) is the anomaly: that agent had been resumed via
SendMessagein between, which appears to have re-registered it.What does work (for contrast)
SendMessageaddressed by agent id revives a completed agent ("was stopped (completed); resumed it"). Addressed by agent type it fails with "no reachable agent by that name".Same failure via backgrounded Bash
A subagent's own
Bash(run_in_background: true)task is no better. 2026-08-27: a CI-watching subagent backgrounded its wait because the 600s foreground cap would have been exceeded, then ended its turn. The child completed ~20 minutes later; the subagent was never revived. The verdict was only recovered because the top-level session had independently armed its own watcher on the same file.Impact
In the original incident a correct CI verdict sat unread for 21 minutes: the subagent had reported "watch armed, I'll report when it fires", and nothing was ever going to fire it. The promise reads as a valid contract to both the agent and the person reading the transcript, and it is backed by nothing.
The workaround is to forbid the pattern outright in subagents — a watching subagent must hold its turn open with a foreground
Bashuntil-loop (re-run on exit 124), and the caller must additionally own a deadline and do one cheap direct read if the silence exceeds it. That works, but it means a subagent cannot absorb a wait longer than its foreground budget without the caller duplicating the watch.Possibly related
enqueuePendingNotificationwithpriority="later"emitsqueueChanged, but the consumer only re-triggers forpriority="now". Same shape — an enqueued notification with no consumer to drain it — though that report is about an idle top-level session under stream-json, and this one is about a completed subagent under the interactive CLI.<task-notification>payloads.Ask
Either:
SendMessageby agent id already resumes a completed agent; orMonitortool description and make the call fail loudly (or warn) when a subagent arms a persistent monitor it will never see fire.Silent non-delivery is the worst of the three, because the agent confidently reports that the watch is armed.