TUI composer stops applying keyboard input mid-turn after a fast unbracketed text burst; stdin still read and the turn keeps running (0.154.0, Linux)

What version of Codex CLI is running?

codex-cli 0.154.0 (npm package, native x86_64-unknown-linux-musl binary)

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-6-astra, model_reasoning_effort = "xhigh"

What platform is your computer?

Linux 7.2.5-200.fc44.x86_64 x86_64 unknown (Fedora Linux 44)

What terminal emulator and version are you using (if applicable)?

Orca 1.4.204, an Electron IDE whose terminal panes are xterm.js and whose PTYs are held by a daemon that outlives the GUI. No tmux, screen or zellij. PTY chain: host PTY → a shell autosuggestion wrapper that allocates its own PTY → zsh → codex. The pane was 152x71. Codex had enabled bracketed paste (CSI ?2004h) and focus reporting (CSI ?1004h).

Codex doctor report

not run: the affected session was live and I did not want to touch its Codex home; can be added on request

What issue are you seeing?

In a long-running turn, the TUI composer stopped applying keyboard input partway through a fast burst of text, and stayed that way for hours. Stdin keeps being read, the TUI keeps rendering, and the model turn keeps running normally.

• The composer is frozen on the first 68 characters of a 254-byte single-line message. The CR that ended the burst never produced a submission.
• Later typing (letters, Backspace) and focus events have no visible effect.
• The "Working (… • esc to interrupt)" timer keeps advancing, and new tool output keeps appearing.

Evidence gathered read-only from the live process:

• Stdin is being consumed, so the loss is inside Codex. While I typed a test burst, /proc/<pid>/task/<input thread>/io rchar rose by exactly 1 per key and by 3 per focus event. FIONREAD on the PTY stayed 0.
• The reader is listening. The input thread sits in epoll_pwait with fd 0 registered (EPOLLIN|EPOLLET|EPOLLRDHUP).
• Codex received every byte. A passive scan of process memory (/proc/<pid>/mem) finds the whole input stream in read buffers: focus events, Ctrl+U, the complete 254-byte sentence, CR, then the later test letters and DEL bytes. No ESC[200~ or ESC[201~ appears anywhere in process memory, so this was not a bracketed paste.
• Composer state has only the prefix. The composer-text copies in memory hold just the 68-character prefix, and the host's independent headless screen mirror shows the same prefix in the composer row.
• No submission was dispatched. codex_core::session::handlers logs no submission for the thread after the one that started the current turn. queue_1.sqlite has no queued items.
• The log DB has no ERROR or panic rows in the window. The app-server connection saw only periodic rate-limit polls.

What steps can reproduce the bug?

Not reproduced deliberately yet. Conditions when it happened:

1. A TUI session about 10 hours old, 1–2 hours into a single long-running turn. The turn had many exec tool calls, native subagent calls (followup_task, send_message, wait) and the "1 background terminal running" status indicator. [tui] pet = "fireball" was on, and the status animation produced a steady ~48 KB/s of output.
2. The host wrote one fast burst to the PTY without bracketed-paste markers: ESC[I ESC[O … Ctrl+U <254-byte ASCII sentence> CR. The host's plain text+Enter send path writes text followed by \r.
3. The composer showed the first 68 characters and never updated again. All later input was ignored.

Thread id is available on request.

What is the expected behavior?

The burst is inserted into the composer and the trailing CR steers or queues it, as with typed input. At minimum, the composer keeps accepting later keystrokes even if a burst is misclassified.

Additional information

Possibly related:

• #28167: composer wedges when a paste is followed immediately by Enter (bracketed-paste state not exited before submit). This case differs: there were no bracketed-paste markers, the composer kept a plain-text prefix rather than a [Pasted Content] placeholder, and every later keystroke was ignored too.
• #38977: Enter downgraded to queued follow-up during a long-running goal until restart.
• #12645: Enter stops responding after task completion in tmux (keyboard enhancement flags).

Workaround: none found inside the session. The agent could still be reached through an out-of-band channel it was polling, and was handed off to a fresh process.

Start by tracing the TUI input reader and composer dispatch, including the codex_core::session::handlers entry point mentioned in the report. Investigate the plain-text burst, CR submission, and subsequent keystrokes during a long-running turn; done means input continues updating and the burst can submit or queue without wedging the composer.