[BUG] Windows: two Bash tool calls never return and never time out — main session deadlocks for 53 min; agent completions and user input queue behind the dead turn

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Two Bash tool calls issued back-to-back never returned a tool_result and never hit the tool timeout. The session produced no events at all for the next 53 minutes and had to be killed manually.

This is measured from the session transcript, not from impression. Of 166 tool_use blocks in that session, exactly 2 have no matching tool_result — the last two:

| Time (KST) | Tool | Command (truncated) | tool_result |
|---|---|---|---|
| 02:14:22 | Bash | cd <repo> && python - <<'EOF' … in-place edit of a local .py file | never |
| 02:14:28 | Bash | cd <repo>; F="$HOME/AppData/Local/Temp/claude/<project>/<other-session-id>/tasks/<id>.output"; ls -la "$F" … | never |

Both are trivial local commands that normally finish in well under a second. The default Bash timeout is 120 s; neither timed out. The two assistant messages are chained (parentUuid of the second == uuid of the first) with no tool_result message between them.

After 02:14:28 the transcript contains no assistant event of any kind until the user typed at 03:07:41 — 53 minutes later.

Timeline (from the transcript)

02:11:53–02:12:39  4 background agents spawned (Agent tool, named).
                   All 4 acked "Spawned successfully" within 20 s.
02:12:41–02:14:13  Parent keeps working normally (Bash, Write) — results arrive fine.
02:14:22           Bash #1 dispatched .............................. no result, ever
02:14:28           Bash #2 dispatched .............................. no result, ever
       (53 minutes of complete transcript silence)
03:07:41           User types; message is ENQUEUED at 03:07:43 (not processed)
03:08:47           Queue drains (dequeue ×2), user sends "answer me"
03:08:48           Last event. User force-kills the session.

Two side effects of the deadlock, both user-visible and both initially mistaken for the primary bug:

1. Background agent completions never surfaced. Two of the four agents had reported before 02:14 and their results were absorbed normally. The other two finished later; their completion notifications had no turn to be absorbed into, so from the operator's seat those two agents looked hung. They were not — when the same two tasks were re-run in a fresh session they completed in ~15 and ~20 minutes and reported normally. This is consistent with #91503 (a queued notification is only ever absorbed_mid_turn), except here the turn never ended because the tool call never returned.
2. User input queued instead of interrupting. The message typed at 03:07:41 was enqueued and sat for 64 s. Pressing escape did not recover the session; only killing the process did.

What Should Happen?

• A Bash tool call that exceeds its timeout should fail with a timeout error and return control to the session. A tool call should never be able to strand a session indefinitely.
• If a tool call is genuinely unbounded, the session should still be interruptible (escape / new user message should preempt a stuck tool), rather than queueing input behind a turn that can never complete.

Environment

| | |
|---|---|
| Claude Code | 2.1.259 |
| Model | Claude Fable 5.1 (claude-fable-5-1) |
| OS | Windows 10 Home 19045 |
| Shell for Bash tool | Git Bash |
| Session ID (deadlocked) | 2000303f-88cf-4b66-9835-7795a4d75359 |
| Concurrent load | one long-running background Bash task (a ~15 min local DB job) started by an earlier session, plus 4 background agents |
| Tooling weight | 7 MCP servers/connectors contributing well over 100 tools, plus a large skill set |

Notes

This recurs at model-release boundaries. The operator reports that parallel/subagent work was reliable before the Fable 5.1-capable build and has been failing repeatedly since. That matches the shape of #37521, filed at the previous boundary ("agents worked reliably before the Opus 4.6 release; freezes increased after upgrading"), which was closed as not planned. #37521 also noted a correlation with heavy system prompts and large tool counts; this environment fits that profile.

The failure is not specific to a particular agent framework. The four agents here were built-in general-purpose subagents; the operator reports the same stalls with a plugin-provided agent framework. The stuck calls themselves were plain Bash, so the common factor is the tool-dispatch/turn layer rather than agents.

Related, and why this is not one of them:

• #91503 — same "queued notification has no idle-wake consumer" mechanism, but there the subagent is idle and the main session is healthy. Here the main session is stuck mid-turn on a tool call, which is what prevents the notifications from ever being absorbed.
• #44783 — closest prior report of a parent deadlock with no timeout or recovery (closed as not planned). There the stuck call was a subagent tool; here it is Bash in the main session, with transcript-level proof that only 2 of 166 calls lost their result.
• #61405 — the general "no timeout, no monitoring, no abort" gap (closed as not planned).
• #78313, #89124 — subagent-side variants of the same missing-timeout class.

What would help

Even without a root cause, a client-side hard timeout on tool dispatch that surfaces as a normal tool error would turn this from "kill the session and lose the turn" into a retry. The work itself survived here only because agent results had been written to files outside the session; anything held only in the turn was lost.