Orchestrator crashes on burst of simultaneous background agent completions

Summary

Claude Code orchestrator process silently crashes when multiple background agents complete simultaneously after an idle period, killing the tmux session with no error output.

Environment

• Claude Code: 2.1.87
• Node: v24.14.1 (running process) / v22.22.0 (system)
• OS: Ubuntu 24.04, Linux 6.8.0-106-generic, aarch64 (Hetzner VPS)
• tmux: session-based workflow, 4 sessions

Steps to reproduce

1. Start an orchestrator session that spawns 3+ background agents via the Agent tool with run_in_background: true and isolation: "worktree"
2. Let the orchestrator go idle while agents work (~12 minutes in this case)
3. Multiple agents complete within <1 second of each other

What happened

• 4 task notifications were enqueued within 250ms (12:35:26.821–12:35:27.073)
• Only 1 was dequeued and delivered as a user message
• Zero assistant response was generated — the process died mid-processing
• 3 notifications remained stuck in the queue
• last-prompt was saved (shutdown handler ran), but no error was logged
• The tmux window/session closed because the process exited

Timeline from session log (5c8333cf)

12:23:32  Last assistant message: "Still waiting on agents 1a and 1b"
          ---- 12 minutes idle ----
12:35:26  enqueue agent-1a result (a76ee7f76a1fcd4da)
12:35:26  dequeue → user message delivered
12:35:26  enqueue agent-1b result (a594a392bdfa8d07c)  
12:35:27  enqueue sub-task result (b2tepnc0i)
12:35:27  enqueue sub-task result (bskrvmr1a)
12:35:27  user message logged (agent-1a notification)
          ---- NO ASSISTANT RESPONSE ---- process dead
12:36:00  tmux pts/14 logged out, session destroyed

What I expected

The orchestrator should process all agent completions and continue the conversation, or at minimum surface an error message rather than silently dying.

Evidence it's not an OS/resource issue

• No OOM kills (8.4GB free, no swap pressure)
• No dmesg or journalctl errors
• No core dumps
• Load average was high (22 over 15min) from the agents but had dropped to 0.46 by investigation time
• Other 3 tmux sessions + their Claude processes were unaffected

Collateral

• 1 of 3 agents had already delivered (PR created)
• 2 agents completed their work (branches pushed) but the orchestrator died before confirming their results or creating PRs
• 3 orphan git worktrees left behind (not cleaned up)
• Session log: 271 entries over 5.5 hours, including multiple >80KB tool outputs hitting persisted-output limits — large context may have contributed

Possible root causes

1. Queue race condition: Burst of 4 enqueues with only 1 dequeue suggests the notification queue handler can't safely process concurrent completions
2. API error after idle: 12-minute idle period may have caused a stale connection, and the error wasn't handled gracefully
3. Context overflow: 5.5-hour session with large persisted outputs — the final notification may have exceeded context limits, causing an unhandled rejection