Background-task completion notification enqueued but never delivered; subagents never re-invoked despite 'You will be notified' ack

Summary

A background Bash task's completion notification was enqueued into the session queue but never delivered — no matching remove/attachment ever appears in the transcript. The session's model never learned the task finished, orphaning an 11-minute compute result. Separately (and compounding it): a subagent that launches a run_in_background Bash command and ends its turn is never re-invoked when that command completes, even though the tool result shown to the subagent says "You will be notified when it completes."

Environment

• Claude Code 2.1.223 (macOS, darwin arm64) at incident time; behaviors re-verified on 2.1.226 (the subagent no-re-invocation reproduces on 2.1.226; the lost enqueue was observed on 2.1.223).

Repro / evidence (transcript forensics)

1. A subagent (spawned via the Agent tool) ran a long external command with run_in_background: true (an ~11-minute codex CLI audit), received the ack "Command running in background with ID: … You will be notified when it completes," emitted its final message (stop_reason: end_turn), and its transcript ends there — it was never re-invoked. (Re-reproduced on 2.1.226 with a trivial sleep 20 && echo done: the background child completes and keeps running orphaned; the subagent transcript never gains another entry.)
2. When the background child completed, the PARENT session's transcript logged {"type":"queue-operation","operation":"enqueue", …} carrying the <task-notification> for the child task id — but no remove operation and no attachment delivery for that notification exists anywhere in the transcript (verified exhaustively; the same transcript shows the normal enqueue→remove→attachment triple for a different notification minutes earlier, so the delivery path was otherwise working). The session was idle at enqueue time; a user prompt arrived ~4 minutes later; the queued notification was silently dropped.

Impact

The completed work's result was stranded — the session concluded the background task had stalled and re-ran an expensive duplicate. Any workflow that trusts "You will be notified when it completes" can silently lose completed work: (a) subagents can never honor that promise (structural), and (b) even main-session notifications can be lost between enqueue and delivery (the queue defect).

Expected

• Either subagents receive completion re-invocation for their background tasks, or the ack text shown inside subagents should not promise notification.
• An enqueued task-notification should be guaranteed delivery (or persist across the next user turn), never silently dropped.