Background subagent task-notification: envelope task-id doesn't match result content (at-rest agents emit sibling agents' updates)

Bug: background subagent task-notification envelope task-id does not match result content (at-rest agents emit commentary about sibling agents)

Component: Claude Code — background subagent / Agent tool task-notification routing
Version: Claude Code 2.1.179
Platform: macOS 26.5.1 (arm64), bash
Severity: Medium — notification stream is unreliable as a completion/result signal; misleads the orchestrating agent. Workaround exists (verify via durable side effects).

Summary

When background subagents are dispatched sequentially (await A, then dispatch B), an already-completed/at-rest agent A fires an additional task-notification whose <result> body describes a different, later agent's task (B), while the envelope <task-id> is A's. The id and the payload disagree, so the parent cannot trust which task a notification actually reports.

Environment / setup

• Orchestration: superpowers:subagent-driven-development — one implementer subagent per task, then one reviewer subagent, dispatched one at a time (each awaited before the next).
• All subagents launched via the Agent tool as background jobs (general-purpose, models sonnet/haiku).

Observed timeline (this session)

Agents dispatched, in order:

1. a58cd1e0… implementer "Task 1: scaffolding"
2. ac5542b0… reviewer "Review Task 1" → FAILED: "previous Claude Code process exited, in-process state was lost"
3. af2791713… reviewer "Review Task 1" (re-dispatch)
4. a9d24052… implementer "Task 2: parser"
5. a3e1048f… reviewer "Review Task 2"
6. a95c21a5… implementer "Task 3: inventory"
7. aff85eae… reviewer "Review Task 3"

Mismatched notifications (envelope id ≠ content):

• Envelope <task-id>a58cd1e0</task-id> (the Task 1 implementer) fired a second notification whose <result> read "The independent review of Task 1 has completed and returned Approved…" — i.e. reviewer content under the implementer's id. The reviewer was a separate agent (ac5542b0).
• Envelope <task-id>af2791713</task-id> (Task 1 reviewer) fired a second notification whose <result> read "…notification that Task 2 has completed." — Task 2 content under Task 1's reviewer id, while the Task 2 implementer (a9d24052) was the active agent.
• Envelope <task-id>a3e1048f</task-id> (Task 2 reviewer) fired a second notification whose <result> read "…notification about Task 3 completing." — Task 3 content under Task 2's reviewer id, while the Task 3 implementer (a95c21a) was active.

Correct notifications (for contrast): each agent's first notification carried its own correct content; the final reviewer (aff85eae) fired correctly with no mismatch.

Pattern

An at-rest agent appears to be woken by a sibling agent's completion event, generates commentary about that sibling's task, and re-rests — emitting a notification with its own (older) task-id but content pertaining to the newer sibling. The documented "same task-id may notify more than once" behavior is being combined with wrong/sibling content, which is not expected.

Steps to reproduce

1. Dispatch background subagent A via the Agent tool; await its completion notification.
2. After A is at rest, dispatch background subagent B.
3. When B comes to rest, observe that A also fires a task-notification whose <result> describes B's task, not A's.

(Reproduced 3× in one session across implementer→reviewer→next-implementer sequences.)

Expected

A task-notification for <task-id>X</task-id> should carry only agent X's own status/result. An at-rest agent should not wake to author commentary about sibling agents it has no stake in.

Actual

At-rest agents emit extra notifications whose body is a sibling agent's status/verdict, under the at-rest agent's id. The notification stream therefore cannot be trusted to indicate which task finished or what its result was.

Impact

• Orchestrating agents (e.g. subagent-driven-development controllers) are misled about task completion and review verdicts.
• Forces a workaround: ignore notification text and verify completion via durable side effects (git log, written files, test runs).

Secondary issue (same session)

Reviewer subagent ac5542b0 returned status=failed: "Background agent was running when the previous Claude Code process exited and did not complete. Its in-process state was lost." A parent-process exit killing an in-flight background subagent (with no resumption) is a separate robustness gap worth noting.

Suggested fix direction

• Ensure a task-notification is emitted only for its own agent's state transitions; do not wake at-rest agents on sibling completion events, or scope each agent's notification content strictly to its own transcript.
• For the secondary issue: persist/queue background subagent state so a parent-process restart can resume or cleanly re-dispatch rather than losing state.