CLI trust prompt exits when split terminal Device Attributes tail is read as input

What version of Codex CLI is running?

codex-cli 0.142.5

The same startup-probe logic also appears to be present on current main as of cca16a1 (codex-rs/tui/src/terminal_probe.rs still uses the 100 ms startup probe deadline and does not drain an incomplete primary Device Attributes response before returning to normal TUI input).

What subscription do you have?

Not relevant to the failure mode; the TUI exits at the directory trust prompt before any model request. I can provide this if maintainers need it for triage.

Which model were you using?

Not model-specific. The TUI exits at the directory trust prompt before any model request.

What platform is your computer?

Linux x86_64, Debian 13 over SSH.

Suggested exact command to paste from the affected shell:

uname -mprs

What terminal emulator and version are you using?

Affected session is over SSH with TERM=xterm-256color. Server-side detection did not identify the terminal emulator. No active tmux server was detected in the capture.

Please fill in the local terminal app/version if known.

Codex doctor report

Not included yet because the affected machine currently has a local patched binary installed, so runtime.provenance would report a local build rather than the original installed package. The captured pre-patch run was on codex-cli 0.142.5, Debian 13, SSH, TERM=xterm-256color.

I can provide a fresh codex doctor --json from an unpatched binary if maintainers need it, but the key signal here is the terminal I/O trace below.

What issue are you seeing?

When launching Codex in a directory that has not yet been trusted, the trust prompt appears briefly and Codex exits with status 0 without any user input.

It behaves as if option 2. No, quit was selected automatically. Disabling keyboard enhancement probing avoids the failure, but that is not a good workaround because it disables keyboard protocol behavior needed for input such as Shift+Enter.

Captured Codex log:

Codex exit status: 0
2026-07-07T14:39:26.983401Z  INFO codex_tui::tui: terminal startup probes completed duration_ms=100 cursor_position=true default_colors=true keyboard_enhancement_supported=Some(true)

Relevant terminal I/O after the prompt is rendered:

write(1, "... 1. Yes, continue ... 2. No, quit ... Press enter to continue ...", 369) = 369
read(0, "\x32\x3b\x32\x33\x3b\x32\x34\x3b\x32\x38\x3b\x33\x32\x3b\x34\x32\x3b\x35\x32\x63", 1024) = 20

The read bytes decode to:

2;23;24;28;32;42;52c

That is the tail of a primary Device Attributes response. Because the first byte is ASCII 2, the trust prompt treats it as selecting No, quit.

What steps can reproduce the bug?

This needs a terminal/SSH/PTY path that splits the primary Device Attributes response so the prefix is read during Codex's 100 ms startup probe and the tail arrives after the trust prompt is already active.

On the affected terminal:

mkdir -p /tmp/codex-trust-untrusted-repro
unset CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT
codex --no-alt-screen -c log_dir=/tmp/codex-debug -C /tmp/codex-trust-untrusted-repro

Observed result: the trust prompt flashes, then Codex exits status 0.

For diagnosis:

strace -f -ttt -s 1024 -e trace=read,write,poll \
  -o /tmp/codex-trust.strace \
  codex --no-alt-screen -c log_dir=/tmp/codex-debug -C /tmp/codex-trust-untrusted-repro

In the failing capture, Codex reports keyboard_enhancement_supported=Some(true) at exactly the startup probe deadline, renders the trust prompt, and then reads the delayed PDA tail (2;23;24;28;32;42;52c) as normal input.

What is the expected behavior?

The directory trust prompt should remain open and wait for an explicit user selection. Terminal probe response bytes should not be interpreted as trust prompt input.

Additional information

Likely root cause:

• terminal_probe::startup() sends batched startup probes, including CSI ? u for keyboard enhancement support and ESC[c as the primary Device Attributes fallback.
• In read_startup_probe(), the probe returns when the 100 ms deadline expires or poll_readable() times out.
• parse_keyboard_enhancement_support() can mark keyboard support as present after receiving keyboard flags, while the primary Device Attributes fallback response is still only partially received.
• If the buffer ends with an incomplete PDA prefix at the deadline, the unread PDA tail remains in the terminal input stream.
• The trust prompt then starts normal TUI input, reads the PDA tail, and interprets the leading 2 as the No, quit menu choice.

Proposed low-risk fix:

Before returning from read_startup_probe() on timeout/poll expiry, if the keyboard probe was queried and the current probe buffer ends with an incomplete primary Device Attributes-like suffix (ESC[? followed only by digits/semicolons, with no final c yet), do a bounded drain read for that response only. Return as soon as the PDA completes or no more bytes arrive. This avoids a global startup delay and keeps keyboard enhancement support enabled.

A local patch using a 1 second maximum drain, only in that partial-PDA state, fixed the issue in the affected terminal and passed focused codex-tui terminal probe tests.