Background-agent completion notifications silently dropped on 2.1.179 (sequential dispatch; agents complete cleanly, no task-notification fires)

Description

In a sequential subagent-driven-development workflow (orchestrator dispatches one background Agent(), waits for its task-notification, then dispatches the next), some background agents complete normally — write their final report, exit cleanly — but the task-notification never arrives on the orchestrator's inbox at all. Not on the agent's own task ID, not on any other agent's ID. Completely silent.

This is distinct from #68065 (which describes notifications re-routed to the wrong task ID — there the notification still fires somewhere) and from #60001 (which requires ≥3 parallel dispatches — here the dispatches are strictly sequential).

Version

• Reproduces on: 2.1.179
• Platform: macOS 14.4.0 (Darwin 25.4.0)

What I observed

Over a ~5-hour subagent-driven-development run executing a 9-task implementation plan with one background general-purpose agent dispatched per task (waiting for each notification before dispatching the next), two out of ~12 agents completed cleanly but their notifications never arrived:

1. Agent A (a3a255cd8bef2f121, a spec-compliance reviewer)
2. Agent B (a78cdfdfe314e5cad, a Task 5 implementer)

For both, the agent transcript shows a normal completion:

Agent A timeline (from agent-a3a255cd8bef2f121.jsonl, 40 lines):

• 03:31:58 — user prompt + attachments
• 03:32:01–03:33:01 — assistant runs 17 tool calls (Bash + Read for code inspection)
• 03:33:31 — assistant emits final text: \Everything checks out. Here is the full findings report: ---\ followed by the full review
• Total runtime: 93 seconds. Final assistant message present. No notification ever received by the orchestrator.

Agent B timeline (from agent-a78cdfdfe314e5cad.jsonl, 16 lines):

• 03:59:15 — user prompt
• 03:59:20 — Write tool (creates the new Swift file)
• 03:59:22–03:59:36 — Bash tool calls (build, commit, verify-commit-landed)
• 03:59:39 — assistant emits final text: \## Report **Status:** DONE **Build result:** ✅ \ BUILD SUCCEEDED \\ and the rest of the report
• Total runtime: 24 seconds. Commit landed in git (d497641). Final assistant message present. No notification ever received.

In contrast, ~10 other agents in the same session dispatched and notified normally.

Side-effect: ghost re-firing of completed agents

While Agent A was running, two previously-completed agents (Task 1 implementer and Task 4 implementer) fired ghost \task-notification\s with their own task IDs, containing text like \"Acknowledged. The spec-review notification confirms my Task 1 implementation is fully spec-compliant\" — text the agents never actually generated (verified against their transcripts). The Task 4 ghost-notification arrived with body claiming \"Task 5 notification noted (CaughtUpDivider component completed, commit d497641)\" — relaying the result that Agent B should have sent on its own ID.

This suggests the notification dispatch layer is doing some kind of misrouting under specific conditions, possibly related to the sub-agent nesting feature mentioned in #68065's diagnosis.

Impact

Orchestrators waiting on background-agent notifications to gate progression block indefinitely. The only recovery is for the user to interrupt (\"are you stalled?\") and have the orchestrator switch to out-of-band verification (\git log\ for implementers, file-mtime polling for reviewers).

For long-running multi-agent workflows (the subagent-driven-development pattern), this turns a smooth automated flow into one requiring human babysitting.

Workaround used

After two notification drops, I stopped relying on background notifications and verified each agent's completion by:

• Checking \git log\ for implementer commits
• Inline-reviewing the diff myself for reviewer agents

Repro suggestion

The plan-execution flow that reproduced this: 10+ sequential \Agent()\ dispatches with \run_in_background: true\ (Claude Code dispatches all subagents in the background automatically), each waiting for the prior's task-notification before dispatching the next. ~17% of dispatches in my session silently dropped notifications. I don't have a minimal repro — it appears to be non-deterministic. Worker reuse across dispatches (raised as a hypothesis in #68065) could plausibly explain the intermittence.

Transcript files (for harness debugging)

• Agent A (silent-drop): \f849f427-b9ee-43b5-9232-254963bfec72/subagents/agent-a3a255cd8bef2f121.jsonl\
• Agent B (silent-drop): \f849f427-b9ee-43b5-9232-254963bfec72/subagents/agent-a78cdfdfe314e5cad.jsonl\

Both transcripts show clean completion with final assistant text. Happy to attach them to a private channel if useful.

Related issues

• #68065 — wrong-agent-ID routing on 2.1.172–176 (sequential dispatch). Could be the same root cause with a different manifestation.
• #60001 — silent drops with ≥3 parallel dispatches. My case is sequential, but possibly the same notification-dispatch layer.
• #67784 — duplicate notifications under same task ID on 2.1.174. Related ghost-firing behavior.

🤖 Generated with Claude Code