Parent session deadlocks when subagent tool execution hangs — no timeout or recovery
Resolved 💬 6 comments Opened Apr 7, 2026 by GrahamJenkins Closed Jun 3, 2026
Summary
Parent session becomes completely unresponsive when a subagent's tool execution hangs. No timeout fires, no circuit breaker kicks in, and user messages queue indefinitely without being processed. Session was stuck for 7+ hours until manually killed. Pressing escape multiple times does not interrupt the agent/subagent.
Steps to Reproduce
- Launch two subagents in parallel (foreground/blocking) via the Agent tool
- One subagent's Bash tool call (in this case,
curlto GitHub API) hangs indefinitely - Parent session blocks waiting for both agents to return
Observed Behavior
- First subagent (
a3d5e...): Only 5 messages in its log. Last message is atool_use(Bash) withstop_reason=tool_use— waiting for tool results that never came. No timeout fired. - Second subagent (
aaa4c...): Completed its work (33 messages, multiple WebFetch calls, produced results) but its result was never delivered back to the parent session. - Parent session: After the two Agent tool calls, there are zero
tool_resultentries. The parent was permanently blocked. - User messages: Follow-up messages at 09:49 and 09:51 were enqueued but never dequeued. Multiple popAll/re-enqueue attempts ~7 hours later also failed to unblock the session.
- Only recovery: Manually killing the session process.
Expected Behavior
- Subagent tool calls should respect the standard 2-minute timeout
- If a subagent hangs, the parent should detect it (watchdog/circuit breaker) and either kill the subagent or return an error
- The parent session should remain responsive to user input even while subagents are running, or at minimum allow interruption
- Completed subagent results should be delivered to the parent regardless of sibling subagent state
Environment
- Claude Code CLI (remote session via claude-screen)
- Model: claude-opus-4-6
- Platform: Linux (Fedora 43)
- Session ID:
3893c609-e6ab-43d0-9073-ebdc6d4ed0d2
Session Log Evidence
Parent session log shows the deadlock clearly:
09:34:32 [queue-operation] enqueue (user message)
09:34:32 [queue-operation] dequeue
09:34:36 [assistant] stop=None
09:34:40 [assistant] stop=None (launches agents)
09:34:46 [assistant] stop=tool_use (Agent tool calls)
09:36:44 [user] (empty — likely agent notification that was never processed)
09:49:52 [queue-operation] enqueue (user follow-up — never dequeued)
09:51:50 [queue-operation] enqueue (another follow-up — never dequeued)
16:54:04 [queue-operation] popAll (7 hours later, user trying to unstick)
... multiple popAll/enqueue cycles, none successful
No tool_result entries exist after the Agent tool calls — the results were never delivered.
This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗