[BUG] Long-running session (Opus 5 1M, Windows) freezes permanently the moment AskUserQuestion renders - event loop deaf to input and resize (v2.1.220)

Summary

A long-running interactive session froze at the exact moment it rendered an AskUserQuestion prompt: the UI painted fully, then the process went permanently deaf — no reaction to any keyboard input or terminal resize. Second freeze of the day in the same project (the first killed a session mid-tool-run 30 minutes earlier). Appears to be the same family as #20572, but with substantially more diagnostic evidence, gathered while the process was still wedged.

Environment

• Claude Code 2.1.220, native install, Windows 11 Pro 26200
• Terminal: ConPTY inside psmux (a native-Windows tmux reimplementation; TMUX env var set, TERM=xterm-256color), hosted in a WPF embedded terminal
• CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 present in env
• Model: Opus 5 with 1M context ([1m]), session ~2.5 h old, ~26% context used, heavy tool use, plan mode active
• Launched with --dangerously-skip-permissions

What happened

1. Session working normally for ~12 minutes on a planning task (tool calls all fine, streaming fine).
2. At 18:09:02 it emitted an AskUserQuestion tool_use (3 questions, 4 options each, with multi-line preview fields). Transcript entry has stop_reason: "tool_use" — the turn completed normally.
3. The question UI rendered completely (tab bar + question text + options, verified via server-side capture-pane).
4. From that instant the process stopped responding to everything.

Evidence the process (not the terminal) is wedged

• Keyboard input injected server-side via the multiplexer (send-keys Down, verified working against a control pane) produced 0 ms CPU delta and no screen change.
• Terminal resize events produced no reflow/re-render (a live Ink app always re-renders on resize).
• Process state: alive, 25 threads, no child processes, ~15 ms CPU per 5 s (timers only), never wrote to the transcript again.
• The window's normal input path also dead (user-reported: "question visible, keys dead").

What it is NOT (all exonerated by controlled reproduction on the same machine, same stack)

Fresh claude processes under the identical psmux/ConPTY stack were driven via send-keys and all of these worked perfectly, selection moving instantly:

• a simple 1-question prompt in a live interactive window (answered by the user)
• a 3-question prompt with multi-line previews
• the byte-for-byte identical questions JSON replayed from the frozen session's transcript
• the same payload while in plan mode
• the same payload launched in the same project folder with its hooks/settings loaded

So: not the multiplexer, not the prompt shape/content, not plan mode, not project config — the freeze is internal to the long-running process, and the question prompt is merely where it locked (the earlier freeze the same day happened mid-Bash-tool run: last transcript entries are a normal tool_use + tool_result pair, then silence).

Impact / ask

Only recovery is killing the process and --resume. Two productive sessions lost to this in one day. Happy to provide the full transcripts or run diagnostics if it recurs — it seems reproducible-ish on this machine with long 1M-context Opus sessions.

🤖 Generated with Claude Code