Background task notification enqueued but never delivered when the owning subagent already completed (SendMessage-resumed agent's orphaned Bash task)

Environment

• Claude Code v2.1.207, macOS (darwin 25.5.0), CLI entrypoint
• Main session running a plugin skill that orchestrates subagents (Task tool + SendMessage)

Summary

A <task-notification> for a completed background Bash task was enqueued into the main session's message queue but never dequeued/delivered, even though the session was idle and remained open for many hours afterward. The distinguishing feature of the stranded notification: the background task was started by a subagent that had already returned — the subagent was a Task-tool agent that completed, was then continued via SendMessage (harness replied "had no active task; resumed from transcript in the background"), started a run_in_background: true Bash command during that resumed run, and then completed again, orphaning the task.

Every other task notification in the same session (~25 of them, including three completion notifications for the same subagent) shows enqueue → dequeue within milliseconds-to-seconds in the session JSONL. The stranded one shows only enqueue, forever.

Event sequence (from the session JSONL, timestamps UTC)

1. Main agent launches a subagent via Task; subagent completes at 07:17:15 — notification enqueued and dequeued within 20 ms. Same again at 07:18:08.
2. Main agent continues the completed subagent via SendMessage → result: "Agent … had no active task; resumed from transcript in the background with your message."
3. The resumed subagent starts gh pr checks <N> --watch with run_in_background: true (task id bd48ibvdo), then ends its turn (completes). Its completion notification is delivered normally at 07:27:58 (enqueue 07:27:58.669 → dequeue 07:27:58.686).
4. Main agent ends its turn idle, waiting for the watch task's completion notification.
5. The orphaned background task completes: queue-operation enqueue for its <task-notification> at 07:30:09.494 — no dequeue ever follows.
6. The process is still alive: a system/away_summary event is written at 07:31:07.953. The session then sits idle. The terminal window stayed open for 16+ hours; the notification was never delivered and no further turn ever started.

Last two events of the transcript:

{"type":"queue-operation","operation":"enqueue","timestamp":"2026-07-11T07:30:09.494Z","content":"<task-notification>\n<task-id>bd48ibvdo</task-id>…"}
{"type":"system","subtype":"away_summary","timestamp":"2026-07-11T07:31:07.953Z",…}

Impact

Unattended multi-agent automation dies silently. In our case an issue-fixing orchestration had verified a PR's CI was green and was waiting on this one notification to merge it; the run ended with the PR unmerged and no summary, with no error anywhere. The "away" state is not the cause: three notifications were delivered normally in the minutes immediately before, equally unattended.

Expected

Either (a) the enqueued notification wakes the idle main loop like every other task notification, or (b) if notifications from tasks whose owning (completed) subagent can't receive them are intentionally dropped, they should not be enqueued into the parent's queue at all — and ideally the harness would surface a warning rather than leaving the notification permanently queued.

Repro sketch

1. In a main session, launch a Task subagent and let it complete.
2. SendMessage to the completed agent so it resumes "from transcript in the background".
3. Have the resumed agent start a long-running Bash command with run_in_background: true and end its turn before the command exits.
4. Let the main agent end its turn idle. When the background command exits, its task notification is enqueued into the main session but (in our observation) never delivered.