[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)

Summary

On Claude Code 2.1.162 (Windows), dispatching ≥3 Agent sub-agents in parallel reliably leaves some permanently wedged: they finish their actual work, then return Tool result missing due to internal error to the parent and never terminate. The wedged sub-agents are not killable from the TUI (kill is a no-op), ignore queued feedback (N queued is never consumed), hold an agent slot, and persist indefinitely (observed 8h+). Only a full session restart clears them.

This overlaps the error string in #56869 / #63678, but is a distinct, more severe failure: not "the parent doesn't get a signal," but "the sub-agent itself is unrecoverable and unresponsive to all control inputs."

Environment

• Claude Code 2.1.162
• Windows 11, Git Bash (/usr/bin/bash)
• Model: Opus 4.8 (1M context)
• Dispatch: 3 general-purpose Agent calls in a single message (parallel)

Repro

1. From a parent session, send one message with 3 Agent tool calls (general-purpose), each doing real work: write several files + run shell commands + a test.
2. ~1 sub-agent returns normally; ~2 return Tool result missing due to internal error.
3. The wedged sub-agents then:

• never terminate — show running in the agent switcher for 8h+ (the timer keeps climbing);
• cannot be killed from the TUI — selecting them and issuing a kill does nothing;
• ignore queued input — queuing feedback shows 1 queued, but it is never consumed;
• hold a slot and clutter the switcher.

1. Crucially, their work completed correctly — every file they were tasked to write was on disk and passed a full test suite. So the wedge happens after the work, in the result-return / teardown path.

Expected

A sub-agent that finishes or errors should: propagate a tool-level error for its tool_use_id, terminate, be killable from the TUI, and either consume or reject queued input.

Actual

Permanent, unkillable, unresponsive zombie sub-agent; no error propagation to the parent; queued input silently dropped; survives until a full session restart.

Impact

• Orchestrator gets no result despite the work being done — recovery requires inspecting the filesystem.
• Zombies accumulate across a session, holding slots/resources and cluttering the switcher.
• No programmatic recovery: the wedged agents aren't in the task list, expose no agent-id to the parent, and don't respond to kill or queued input.

Related (but distinct)

• #56869 — same error string, framed as the parent not getting an error signal / apparent hang; does not cover unkillable + queued-input-ignored + multi-hour persistence.
• #49150 (closed) — "Task() has no timeout, subagent hang leaves orchestrator stuck (Windows)"; the no-timeout / no-reaping aspect clearly persists in 2.1.162.
• #63678 — Tool result missing due to internal error is undiagnostic.
• #65413 — same error string + version (2.1.162, Windows) via the MCP-stdio path; likely a sibling manifestation of the same result-handling fragility.

Suggested fix

1. Propagate a tool-level InternalError for the failed tool_use_id so the parent can recover.
2. Add a timeout + forced reaping for sub-agents that don't return, so they can't become permanent zombies.
3. Make wedged sub-agents killable from the TUI, and have them drain/reject queued input.

Workaround

Don't treat the sub-agent's report as the completion signal — inspect the filesystem for the work + re-verify centrally; restart the session to clear zombies.