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

[Seeruhe]

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
  Codex App hang by pasting “\n” character #26326).
• Transport side: default transport=auto prefers WebSocket (responses_websocket); a
  server-side ~300s idle timeout (Codex CLI hangs on Ubuntu during normal prompts #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 macOS local Codex clients hang after sending prompts #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.
2. Fall back from WebSocket to HTTPS faster (current behavior retries ~5×15s per TUI shows "Timeout waiting for child process to exit" when WebSocket transport fails; 75s startup delay before HTTP fallback #22634 before
   falling back).
3. Harden paste handling for multi-line / large clipboard content (Codex App hang by pasting “\n” character #26326).
4. 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

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• [TUI][macOS][Warp] Ctrl+V after copying plain terminal text freezes the TUI #27811
• VS Code terminal input freezes when pasting escaped single-line JSON #27405

Powered by Codex Action

[Seeruhe]

Update — related to #26326 (closed as fixed):

#26326 was closed as fixed ("Version 26.608.12217, Released Jun 9 2026 — bug fixed"), but I can
still 100% reproduce this on Codex CLI 0.139.0 (latest stable, released after Jun 9).

Likely reasons the fix didn't reach the CLI:

1. The fix in Codex App hang by pasting “\n” character #26326 explicitly says "Codex App" (desktop app, version scheme 26.608.x).
   I'm on Codex CLI (0.139.0) — a different product/code path. The App-side paste fix appears
   not to have covered the CLI's paste-handling + WebSocket transport.
2. My repro additionally shows a WebSocket transport hang (tokio-tungstenite poll_next
   looping on WouldBlock, server-side ~300s idle timeout per Codex CLI hangs on Ubuntu during normal prompts #16168), which is orthogonal to the
   App paste fix.

So this is most likely an incomplete fix (CLI not covered), not a regression. Full repro +
logs are in the original report above. Can provide more traces if helpful.