[Bug] Session hangs mid-request 35+ min (API sockets alive, caffeinate respawning), then TUI input freezes entirely — ESC dead, kill+resume required

Bug Description

An interactive session hung mid-turn for 35+ minutes with no output, and the TUI stopped accepting keyboard input entirely — keystrokes were not echoed and ESC did not interrupt. The process had to be killed; --resume then restored the session correctly.

The process was inspected live from a second Claude Code session on the same machine while it was hung, so there is process-level forensic detail below.

Timeline (UTC, 2026-08-11)

• Session running interactively (claude --dangerously-skip-permissions) in a git worktree; process uptime ~31h at time of hang.
• 14:04:46Z — last completed activity written to the transcript: a Bash tool_use and its tool_result. Last completed request: req_011Cdw6386ujPAbBJ847S5cg. The hang is in whatever request followed it.
• 14:04:46Z → 14:40Z+ — zero transcript writes. No api_error / rate_limit / retry breadcrumbs anywhere in the transcript.
• 14:37:09Z — user typed a message into the session; the transcript records a queue-operation enqueue, but it was never delivered/processed.
• Some minutes later, keyboard input stopped working entirely: nothing echoed, ESC had no effect.
• User killed the process. claude --resume restored the session (same session id) and it continued normally.

Live process observations while hung

• Process state S+, ~4–6% CPU — not busy-looped, not zombied.
• It kept re-spawning its caffeinate -i -t 300 child (the observed child was ~2 min old ~35 min into the hang), i.e. the client still believed a request was in flight and the event loop was at least partially alive.
• 4 ESTABLISHED TLS connections to the Anthropic API (2607:6bc0::10).
• Sustained low-rate traffic on those sockets: ~13 KB in / ~15 KB out over a 9-second nettop sample (~1.5 KB/s each way) — a steady trickle, no bursts, for the entire observed period. Consistent with an SSE stream that never completes (or silent retry churn), rather than a dead socket.
• Transcript file mtime frozen at the moment of the last tool_result.

Expected behavior

1. A streaming request that produces no completed message for tens of minutes should time out and surface a visible retry/error.
2. ESC should always be able to interrupt an in-flight request.
3. The input loop should never freeze — the queued-message path was working at 14:37Z (enqueue was recorded) but input handling was completely dead shortly after.

Environment Info

• Platform: darwin (macOS, Darwin 25.5.0)
• Version: 2.1.220
• Model: claude-fable-5
• Session was long-lived (~31h) with an MCP server child (xero-mcp-server) attached

Related

• #81778 reports the same "hangs during thinking, no output" symptom on 2.1.220/darwin, but there ESC works as a recovery. Here ESC and all keyboard input were dead, so kill + --resume was the only recovery.

The full transcript of the hung session is preserved and more detail can be provided on request.

🤖 Filed with Claude Code from a second session that inspected the hung process live.