Subagent task-notifications dropped when child finishes while parent is mid-turn; parent stalls indefinitely

Status Fixed / completed
Reported on v2.1.238
Maintainer reply None cached
Activity 0 comments · opened Aug 21, 2026 · closed Aug 21, 2026

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 own Agent subagents)

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: SendMessage the parent and tell it to read tasks/<task-id>.output for the missing IDs.

I can provide the session id / full transcript privately if useful.

View original on GitHub ↗