TUI input freezes when receiving pasted text from dictation app (Monologue)

Description

Claude Code's TUI occasionally becomes completely unresponsive when receiving pasted text from Monologue, a smart dictation app that copies transcribed speech into the active input field. The process remains alive but the TUI accepts no keyboard input, and even SIGWINCH (window resize) fails to trigger a redraw. Requires SIGTERM to kill.

Steps to Reproduce

1. Start Claude Code in iTerm2
2. Use Monologue to dictate/transcribe text
3. Select the Claude Code input box in the terminal
4. Stop Monologue recording — it automatically pastes the transcribed text into the active input
5. Occasionally (~rarely, not every time), the TUI freezes completely

Expected Behavior

Claude Code accepts the pasted text and displays it in the input field normally.

Actual Behavior

The TUI becomes completely unresponsive:

• No keyboard input accepted (Enter, typing, etc.)
• SIGWINCH does not trigger a redraw
• Process remains alive in S+ state (sleeping, foreground) with low CPU (~0.2%)
• Terminal remains in raw mode (-icanon -isig -iexten -echo)
• Only SIGTERM kills the process

Diagnostic Details

• The session log shows the previous turn completed successfully (stop hook ran, turn_duration was logged). The freeze occurs while waiting at the input prompt, not mid-turn.
• The process has active API connections (ESTABLISHED TCP) and appears healthy from the OS perspective — only the TUI/input handler is deadlocked.

Environment

• Claude Code version: 2.1.39
• Platform: macOS Darwin 24.6.0 (Apple Silicon)
• Terminal: iTerm2
• Dictation app: Monologue (pastes transcribed text into active input field)
• MCP servers active at time of freeze: claude-in-chrome, neon (mcp-remote)

Additional Context

• The freeze is intermittent — Monologue is used frequently with Claude Code and it works fine most of the time.
• This is consistent with a race condition in the ink-based TUI's raw-mode input handler when processing rapid or large text pastes.
• Observed multiple times across different sessions. Previous occurrences were attributed to other causes (Kiro CLI blocking, Context7 MCP server), but those have since been removed and the issue persists.
• The session can be resumed with claude --resume after killing the process, since the conversation log is intact.