Subagent completion notifications are dropped when they arrive while the parent agent is mid-turn, leaving the parent stalled indefinitely
Environment
- Claude Code v2.1.234, macOS (Darwin 25.5.0), CLI entrypoint
- Model: claude-fable-5
- Seen with the built-in
/code-reviewskill (forked background execution), which fans out finder/verifier subagents via the Agent tool
Summary
When a background agent has several async subagents finish in a tight window, completion notifications that land while the parent agent is already mid-turn (processing an earlier completion) are dropped instead of queued. After the parent ends that turn, no pending event remains to re-invoke it, so it idles forever believing subagents are still running — a classic lost-wakeup race. The work is all actually done; only the wake-up is lost.
Evidence
Reproduced twice in one session, both with the same signature:
Run 2 (concrete numbers, from the parent agent's JSONL transcript):
grep -c 'Async agent launched successfully'→ 19 subagents launchedgrep -c '<task-notification>'→ only 15 completion notifications ever delivered to the parent- The 4 missing notifications correspond exactly to the 4 verifiers the parent's final message said it was still waiting on ("Four verifiers still running (…)"). All 4 verifier transcripts end with a completed verdict, mtimes within the same ~60s window (09:04–09:05) — the same window in which the parent was mid-turn handling an earlier completion.
- The parent then sat idle for 2+ hours (mtime frozen) until manually resumed via SendMessage ("your verifiers are done, assemble now"), which unstuck it immediately and produced the complete, correct report.
Run 1 (earlier in the same session): identical pattern — parent stopped with "Six verifiers are still running… Their completion notifications will arrive automatically", all verifier transcripts already finalized within a minute, parent idle 1+ hour until a manual SendMessage nudge.
A secondary symptom: the parent's stop fired a task-notification to the top-level session that claims to fire only "with no live background children of its own" — while the parent itself believed N children were still running. That's consistent with the children having already completed and their events having been consumed/dropped while the parent was busy.
Expected
Subagent completion events arriving while the recipient agent is mid-turn should be queued and delivered when the turn ends (or coalesced into one wake-up) — never dropped. A parent that ends its turn with completed-but-unnotified children should be re-invoked.
Actual
Events completing during the parent's active turn are lost; the parent stalls indefinitely and needs a manual SendMessage to resume.
Workaround
Watch subagent transcript mtimes; when they go quiet while the parent claims to be waiting, SendMessage the parent telling it its subagents are done and to read their transcripts. Works reliably, but defeats unattended multi-agent runs.
🤖 Generated with Claude Code