Subagent task-notifications dropped when child finishes while parent is mid-turn; parent stalls indefinitely
Summary
Background-subagent completion notifications (<task-notification>) are dropped when the child finishes while the parent agent is still inside an active turn. They are never re-delivered, so a parent that fans out N subagents and then "waits" for results stalls indefinitely even though every child finished and its output file is on disk.
Reproduces reliably with /code-review at high effort (forked skill spawns ~16 verifier subagents one per turn; fast verifiers finish mid-fan-out and are lost).
Environment
- Claude Code 2.1.238, macOS (Darwin 25.6.0), zsh
- Invocation:
/code-review --xhigh --comment <PR URL>(runs as a forked background skill agent, which spawns its ownAgentsubagents)
Timeline (from the parent agent's transcript, subagents/agent-aeec4418a3688ebec.jsonl)
Parent spawned 16 verifier subagents sequentially, one Agent tool call per assistant turn:
13:36:40 Agent: Verify #1
13:36:46 Agent: Verify #2
... (~8 s apart)
13:38:52 Agent: Verify #16
13:38:57 text: "Six of 16 verifiers back so far..." <- parent ends its turn
13:39:00 task-notification (verifier finished 13:39:00) delivered
13:39:24 task-notification delivered
...
13:41:04 task-notification delivered
13:41:09 text: "Ten of 16 in ... Waiting on 1, 2, 3, 4, 6, 8." <- stalls forever
Children's completion times vs. whether the parent ever received a notification:
a3446ee0bc7dca08e finished 13:38:17 NOT delivered
a51e812c3b9279188 finished 13:38:09 NOT delivered
aad4dcc061b634e1e finished 13:38:39 NOT delivered
ab281304a3ef495ea finished 13:38:01 NOT delivered
ab7bf94e2d27a8e9a finished 13:37:51 NOT delivered
afb5194ed6867d387 finished 13:38:08 NOT delivered
(all 18 others, finished >= 13:39:00) delivered
The six lost children are exactly the six that completed between 13:37:51 and 13:38:39, i.e. while the parent was still mid-turn issuing the remaining Agent calls. Every child that completed after the parent's turn ended (13:38:57) was delivered. Each lost child's transcript ends normally with stop_reason: end_turn and its tasks/<id>.output file is complete.
Expected
Notifications that fire during an in-flight turn are queued and delivered at the next turn boundary (the <note> text in the notification itself implies they can arrive later: "the same task-id may notify more than once").
Actual
They are silently dropped. The parent has no timeout and no signal that anything was lost, so it ends its turn "waiting" and never resumes. The only recovery was a manual SendMessage to the parent telling it to read the tasks/<id>.output files directly — after which it finished in under 3 minutes.
Secondary issue (same run)
At 13:38:57, before any verifier notification had arrived, the parent emitted "Six of 16 verifiers back so far (2 refuted: ...)" and then corrected itself at 13:39:08 ("no verifier results had arrived at that point"). It appears to have inferred completions from the Agent spawn results. Not the cause of the stall, but it means a user watching the skill's status lines gets a fabricated progress count.
Impact
Any fan-out pattern where the parent spawns sequentially and some children are fast loses the fast ones. /code-review at high/max effort hits this on most runs for me; the skill appears to finish, then sits at "Waiting on N, M, ..." with no further activity.
Workaround
- Spawn the whole batch in a single assistant message (parallel tool calls) so no child can complete mid-turn.
- If already stalled:
SendMessagethe parent and tell it to readtasks/<task-id>.outputfor the missing IDs.
I can provide the session id / full transcript privately if useful.