[BUG] Parallel sub-agents permanently wedge after completing work — unkillable, ignore queued input, "Tool result missing due to internal error", 8h+ zombies (Windows, 2.1.162)

Still present on 2.1.197 (Windows 11, Git Bash). Confirming this is not fixed. Additional data points from my earlier reports that this issue supersedes:

• #56869 — the parent gets no tool-level error signal when the sub-agent returns Tool result missing due to internal error; it just appears to hang.
• #58078 — on msys2, dispatching many parallel Agent calls in one message can wedge the shared bash fork() (exit code 0xC0000142, Resource temporarily unavailable), after which every Bash call in the parent fails until session restart.

A light repro (3 trivial parallel agents, one echo each) completes fine on 2.1.197, so the trigger seems tied to heavier concurrent work / higher fork rate rather than parallelism alone. Suggested mitigations: (1) surface a tool-level error to the parent instead of a silent partial result, and (2) a platform-aware concurrency cap for Agent dispatches on Windows.

Independent corroboration, still happening on 2.1.198 (Windows), so this isn't fixed going into your version either — six days later than the "still present on 2.1.197" comment above.

My shape is slightly different in surface (a lead session under auto mode with several background sub-agents in flight, accessed partly via Remote Control) but matches the core mechanism described here closely:

• The session's background work keeps genuinely progressing — it periodically produces its own status output and even self-initiates new tasks on its own — so it is not dead or crashed.
• Despite that, direct input from me stopped getting any response at all. I sent two separate, explicit messages roughly 4 hours apart; neither was ever acknowledged. A "queued" indicator was visible on at least one of them, consistent with the "ignore queued input" behavior described above — the queued message never got consumed even though the session kept doing other work in the meantime.
• No kill/recovery path available from the client side short of a full session restart, same as reported here.

So: work completing correctly + queued/direct input silently never consumed + only a full restart recovers, on Windows, persisting for hours — same fingerprint, fresher version. I've also written up the broader session-level pattern (a few different manifestations of "background work keeps happening, operator input stops being answered") over on FR #56913 if the fuller timeline is useful context, but this issue looks like the closest match to the actual mechanism.

Follow-up with a more specific mechanism detail, from a raw transcript of the same failure class I described in my comment above.

The "ignore queued input" behavior may actually be a misroute, not a silent drop. In the transcript I have, a background sub-agent finishes (twice) and later genuinely crashes (Agent terminated early due to an API error: API Error: Server error mid-response — a real transient backend error, not a client hang). Each time, immediately after, the log shows the same sub-agent being "stopped (completed/failed); resumed it in the background with your message" — where "your message" was my actual chat input, freshly typed into the lead session.

That input never reached the lead session at all. It was consumed as the resume instruction for the finished/failed background sub-agent instead, three separate times across the same window. The lead session's only activity in that entire span was a handful of self-directed wakeups that just re-read and restated its own existing plan — consistent with it never having received any new input to respond to, because that input was being redirected elsewhere.

If accurate, this would mean the "N queued" indicator isn't just failing to get consumed — it's being consumed by the wrong thing.

Update to the mechanism note above: this reproduces on a brand-new session running the latest patch release (the one whose changelog specifically claims to fix "background sessions becoming permanently unresponsive to attach, replies, and stop when the daemon's session token went stale") — with no prior idle period at all, so the stale-token trigger this release targets doesn't apply here.

The trigger was also different from my last report: a background sub-agent finishing successfully (not crashing/erroring), immediately followed by the same "stopped (completed); resumed it in the background with your message" line consuming fresh chat input that was meant for the lead session.

So two updates: the misroute isn't tied to error-handling on agent failure — an ordinary successful completion is enough to trigger it — and the newest patch doesn't appear to close this. It may only address the specific long-idle/stale-daemon-token trigger named in its changelog, while the broader agent-completion race stays open.

Follow-up with a possible contributing factor, from a fresh instance where the misroute log line was captured directly on the desktop terminal (not inferred): at the same moment the misroute happened, the session also had a pending destructive-command confirmation prompt open (a scoped rm -rf, waiting on a discrete 1/2/3 menu selection). The user had been sending normal chat input during that window, not realizing the CLI was actually blocked on a menu-style confirmation rather than ready to receive a message.

Hypothesis, not confirmed: text arriving while the CLI is blocked on a discrete y/n or numbered-menu confirmation prompt might be getting mishandled — stashed as an unrelated finished/failed background agent's resume input — rather than either answering the pending prompt or reaching the lead session. I don't have visibility into whether earlier instances of this same misroute also had a pending confirmation prompt at the time, so I can't confirm this is the trigger in general, only that it coincided this time. Flagging it as a lead in case it's useful to whoever is tracing the input-handling path.

Density data point from a single continuous session transcript: seven instances of this misroute in one sitting, both variants present ("stopped (completed); resumed... with your message" and "had no active task; resumed from transcript... with your message"). One specific background task finished three times in a row within that session, and each of the three completions immediately swallowed the user's next message the same way — reads like a retry loop where every re-trigger re-creates the same race. Full detail cross-posted on FR #56913 just now.

Scope note, since the density counts I posted above are easy to misread as one bad session: that was roughly a two-hour window, not the whole picture. This same pattern has recurred across multiple separate days now (see the full timeline on FR #56913). It's the steady state, not an isolated incident.

Also explicit: this is on the current CLI release (2.1.203, verified via claude --version), not an old pinned version — and restarting into the latest release does not fix it, confirmed earlier in this thread on a brand-new install that had never gone idle.

Confirmed still present in 2.1.219, MacOS CLI release. At least 3-4 times a day, dispatched agents will hang and further troubleshooting reveals the [Tool result missing due to internal error] condition. Agent zombies waiting on tool output, main session stops processing queued messages, and the only way to recover is to halt the main session and attempt to manually retry/resume the agent dispatch.