[Bug] Bash tool calls hang before dispatch on Windows desktop; Stop ignored until claude.exe killed

Bug Description
Desktop (Windows): Bash tool call hangs forever before dispatch, then the session process ignores Stop and new messages ## Summary In the desktop app (Code tab, local sessions), Bash tool calls intermittently never return. The call shows as "called Bash" in the transcript and the turn sits there indefinitely. No shell process is spawned, the desktop app never emits a permission request for it, and nothing is logged as an error. Pressing Stop does not recover it. The app logs Interrupting session ... and accepts new messages ("queued"), but the session's claude.exe writes nothing more to its transcript: no interrupt marker, no reply. The process stays alive, idle (~0.05 s CPU per 5 s), with no child processes. It looks blocked awaiting something that never resolves. The only way out is to kill that claude.exe. Two sessions were stuck at the same time today (since 08:29 and 08:53 local) and stayed stuck after Stop. A third session on the same machine, also in auto mode, ran Bash and PowerShell normally the whole time. ## Environment - Windows 11 Home 10.0.26200, Claude desktop app, Code tab, local sessions - Claude Code 2.1.295 (the desktop-bundled claude.exe, run with --permission-prompt-tool=stdio --input-format stream-json) - Permission mode: one stuck session in auto, the other launched with --permission-mode acceptEdits (its transcript shows switches between auto and acceptEdits) - Bash tool = Git Bash (MINGW64); PowerShell 7.6.6 also available - Hooks: SessionStart, SessionEnd, SubagentStart/Stop, Stop, UserPromptSubmit, Notification. No PreToolUse hooks (so this looks different from #95354) ## Evidence 1. Transcript (~/.claude/projects/<proj>/<session>.jsonl): tool_use for Bash with no matching tool_result. Today's examples (UTC): - 01:29:17: cd <scratchpad> && python -I script.py <file1> <file2> | head -150 - 01:53:11 and 01:53:13, issued in parallel: git -C <repo> fetch -q origin ... and curl -s -m 20 https://<host>/.... The curl has a 20 s cap, so even a network hang would have returned. 2. No process: while both were stuck, Get-CimInstance Win32_Process showed no bash.exe, git.exe, python.exe or curl under any claude.exe. The commands never started. 3. Desktop log (%LOCALAPPDATA%\Claude\logs\main.log): no Emitted tool permission request for these calls, and no error/warn lines for either session in the window. When I interrupted, the app logged [CCD CycleHealth] healthy cycle for <session> (1998s, hadFirstResponse=true). Separately, one of the sessions had two Emitted tool permission request ... for Glob at 01:12:28 UTC that never received a respondToToolPermission, so read-only Glob was also prompting there. 4. Recurring since ~2026-10-10: scanning the last 4 days of transcripts, trivial read-only Bash calls (cat, grep, awk over markdown docs) took 540 s, 1152 s, 1163 s, 1213 s and 2733 s between tool_use and tool_result, plus 5 calls that never got a result. Before that, slow calls on this machine were genuinely long jobs (test suites, robocopy). ## Expected Either the command runs, or the call fails with a visible error (as in #97854, "classifier gave no verdict"), or a permission prompt appears. It should never hang silently. ## Actual Silent indefinite hang before dispatch. From the UI the session just looks "stuck". ## Possibly related - #97854 / #83773: the auto mode classifier returning no verdict. There it surfaces as an error; here it looks like a hang with no timeout. - #100490: a desktop auto mode Bash permission request pending for 37 h on Windows. - #95354: tool never dispatches after a PreToolUse hook on Windows, but I have no PreToolUse hooks. ## Workaround Stop + "continue" does NOT work. Killing the session's claude.exe and letting the app resume the session is the only recovery I've found. Since --permission-prompt-tool=stdio is in use and neither the tool call nor the interrupt ever gets processed, one guess is that the CLI is waiting on a permission/classifier step whose response never arrives, and control messages queue behind it.

Environment Info

• Platform: win32
• Terminal: windows-terminal
• Version: 2.1.296
• Feedback ID: fb8e2861-eaec-46f1-af34-998e90f23301