TUI freezes 100% when pasting long multi-line text; compounded by WebSocket transport hang (`tokio-tungstenite poll_next` loops on `WouldBlock`)

Summary
Pasting a long, multi-line text into the Codex TUI causes the entire UI to freeze — no keyboard
input is accepted and there is no spinner. The process stays alive (sleeping, 0% CPU), and
logs_2.sqlite shows the main thread blocked in a tight tokio-tungstenite WebSocket read loop
hitting WouldBlock with no timeout. A forced SIGINT is required to recover.

Environment

• Codex CLI: 0.139.0
• OS: Arch Linux, x86_64, kernel 6.x (headless SSH session)
• Auth: ChatGPT login (~/.codex/auth.json)
• Model: gpt-5.5, model_reasoning_effort = "high"
• Config: approval_policy = "never", sandbox_mode = "workspace-write"
• Launch: codex resume --last --dangerously-bypass-approvals-and-sandbox

Reproduction

1. Start an interactive Codex session.
2. Paste a long, multi-line text (a multi-KB markdown document with many \n) into the prompt.
3. Press Enter.
4. TUI freezes completely; no further input is accepted.

Expected: Send the request with a timeout, or reject oversized/malformed input with a clear
error.
Actual: TUI hangs indefinitely; the main thread is blocked and never recovers on its own.

Diagnostic evidence captured

• Process state: Sl+ (sleeping), CPU 0% — blocked, not computing.
• Network to OpenAI is reachable: api.openai.com → 401, chatgpt.com → 403 (normal auth

responses, not a network outage).

• ~/.codex/logs_2.sqlite tail shows a tight loop:

``
[TRACE] tokio-tungstenite .../lib.rs:294 Stream.poll_next
[TRACE] tokio-tungstenite .../compat.rs:154 Read.read
[TRACE] WouldBlock
``
→ blocked on a WebSocket read with no timeout.

• Sending SIGINT flips state Sl+ → R+ (brief wake) then the TUI exits, leaving the terminal in

a dirty state (raw mode not restored; subsequent keystrokes render as garbage like
u;1:3u...).

• Not MCP-related: codex mcp list → "No MCP servers configured".
• Not sandbox-related: sandbox_mode = workspace-write.

Root cause hypothesis

• Input side: TUI paste handling has a known bug with multi-line clipboard content (ref

#26326).

• Transport side: default transport=auto prefers WebSocket (responses_websocket); a

server-side ~300s idle timeout (#16168) leaves the connection half-dead, and the WebSocket read
loop (poll_next) has no reasonable timeout, so the main thread blocks indefinitely. Same
gpt-5.5 + ChatGPT-auth + WebSocket pattern as #13715.

Workaround
Do not paste long text directly. Save it to a file and reference it by path so the agent reads
it via a tool call instead of sending the whole payload over WebSocket.

Suggested fixes

1. Add a timeout on the WebSocket poll_next / read path — fail-fast instead of blocking

forever.

1. Fall back from WebSocket to HTTPS faster (current behavior retries ~5×15s per #22634 before

falling back).

1. Harden paste handling for multi-line / large clipboard content (#26326).
2. Restore terminal state on abnormal exit so a forced interrupt doesn't leave the tty in raw

mode.

Related issues: #26326, #1451, #16168, #13715, #13710, #22634, #17003