[BUG] Completion notifications unreliable for foreground commands auto-backgrounded at the 10-minute cap (inside subagents)

What's Wrong?

A foreground Bash command inside a subagent that exceeds the 600000 ms cap is auto-backgrounded ("Command did not complete within its 600s timeout and was moved to the background (ID: …)"). The stray task's eventual completion notification is unreliable: sometimes it never arrives at the owning agent, sometimes it appears later as a confusing duplicate. A subagent that ends its turn to wait on it can sleep indefinitely.

Our canonical trigger: an ~11-minute test suite run with the default timeout — every such invocation auto-backgrounded, and the agents waiting on the result repeatedly slept until manually nudged (multiple 30–40 min stalls in one week).

What Should Happen?

An auto-backgrounded command should behave exactly like a deliberately backgrounded one (run_in_background: true): its completion reliably re-invokes the agent that owns it.

Steps to Reproduce

1. Spawn a background subagent whose prompt is: "Run python3 -c \"import time; time.sleep(720); print('done')\" as a normal foreground Bash call with the default timeout. When the tool result says it was moved to the background, end your turn and wait for its completion notification. When it completes, report the output."
2. The command auto-backgrounds at the 10-minute cap; the subagent ends its turn (it has a live background task).
3. Observe: after the command finishes (~2 min later), the completion notification is not delivered to the subagent (or arrives only as a duplicate/late anomaly at the session root); the subagent never reports.

Context (shared setup for this report)

We run deep background-subagent trees (session root → coordinator agent → slice agents → task agents, all general-purpose, fork mode on, interactive CLI session). Since all Agent spawns became asynchronous, "end the turn with live background tasks" is the wait primitive: the harness re-invokes the parent when a child completes. That contract holds for fresh spawns — this report is about one specific case where it breaks. Observed across ~9 long autonomous runs on Claude Code 2.1.234–2.1.238 (Linux/Fedora, Anthropic API).

Error Messages/Logs

(see Steps to Reproduce; key strings quoted inline)

Claude Model

Not sure / Multiple models (sonnet + opus subagents)

Is this a regression?

I don't know (observed on every version we ran: 2.1.234 → 2.1.238)

Claude Code Version

2.1.238 (Claude Code)

Platform

Anthropic API

OS

Linux (Fedora 44)

---
Related (distinct bugs in the same subsystem, filed separately per the single-bug rule): #89042, #89043, #89045. Together they make completion delivery unreliable for anything except fresh never-resumed spawns; field evidence: ~4–5 h of stalls across 9 multi-agent runs in one week.