TUI composer wedges on tmux paste-buffer + immediate Enter: bracketed-paste state not exited before submit (codex-cli 0.139.0)

TUI composer wedges on tmux paste-buffer + immediate Enter: bracketed-paste state not exited before submit (codex-cli 0.139.0)

What version of Codex is running?

codex-cli 0.139.0

What platform is your computer?

Linux Ubuntu 24.04.4 LTS, kernel 6.17.0-35-generic, x86_64

What terminal / environment?

• tmux 3.4 (with mouse on, allow-passthrough on)
• TERM=xterm-256color, COLORTERM=truecolor
• codex-cli launched as: codex -C <repo> --sandbox read-only --ask-for-approval never
• (terminal emulator not relevant to the bug; reproduced inside a tmux session)

What steps reproduce the bug?

# 1. In a tmux session with a running codex-cli TUI pane, build a
#    multi-line payload (any text > ~1 KB triggers reliably; small
#    payloads can also trigger under fast conditions).
PAYLOAD='hello test
this is a multi-line test message
line 3
line 4'

# 2. Load + paste via tmux (standard multi-line delivery pattern).
tmux load-buffer -b repro - <<<"$PAYLOAD"
tmux paste-buffer -b repro -t %pane

# 3. Send submit immediately (this is the trigger).
tmux send-keys -t %pane Enter

What is the expected behavior?

The submit gesture sent after the paste is treated as a clean submit. The composer clears, the placeholder returns, and the message is processed.

What actually happens?

The composer renders [Pasted Content NNNN chars] #2 (and #3, #4, ... if multiple submit gestures are sent). Submit gestures (Enter, C-m) are interpreted as additional paste events — the #N counter increments. The composer is wedged; no message is submitted. The wedge persists across C-a + C-k clears of the visible composer line and is only reliably cleared by killing and relaunching the codex-cli process.

Workaround (verified)

Insert a sleep of approximately 5 seconds between the paste-buffer call and the submit gesture. The TUI then exits bracketed-paste state and accepts a clean submit:

tmux paste-buffer -b repro -t %pane
sleep 5                   # required delay; TUI exits paste state here
tmux send-keys -t %pane Enter

This is functional but inelegant. The required delay appears to scale with payload size; 5–10 seconds is a workable default.

Diagnostic observations

• The issue is reproducible across multiple cycles.
• A codex-cli session in the affected environment self-diagnosed: the TUI remains in (or re-enters) bracketed-paste input handling, and the submit gesture is routed through the paste path as a continuation / replay event rather than as a clean submit.
• Web search at the time of this report returned no known openai/codex issue for the same symptom. Search performed: site:github.com/openai/codex codex-cli 0.139.0 paste Enter bracketed paste tmux.

Potentially related issues

• #12645: "Enter key stops responding after task completion in tmux" — similar symptom (Enter stuck in tmux context), root cause traced to KeyboardEnhancementFlags in tui.rs:73-79. May share an underlying input-mode state-machine mechanism.
• #17332: feature request for paste-placeholder settings — adjacent, not the same bug.
• #25346: references chat_composer.rs lines 62–70 and the pending_pastes → prepare_submission_text_with_options pipeline — the same code path. That issue is about Desktop ignoring pasted attachments; this issue is about the TUI submit not expanding pending_pastes. Both involve the placeholder → submit pipeline.

What I haven't tested yet

• Whether the bug reproduces outside tmux (plain terminal paste followed by immediate Enter).
• Whether the bug reproduces with small pastes (a single line, a single word, a few bytes) — i.e., is there a size threshold?
• Whether the bug reproduces with middle-click paste inside tmux (which may use a different code path than paste-buffer).
• Whether codex --no-tui is supported and whether the bug is TUI-specific.
• codex CLI debug-level logs during reproduction.
• Whether the fix for #12645 (PushKeyboardEnhancementFlags in tui.rs:73-79) is in 0.139.0; if it is, this bug is a different manifestation of the same input-mode state-machine issue.

Suggested fix surface

The TUI's input state machine should ensure that:

1. A submit gesture (Enter / C-m) received after a bracketed-paste payload is always routed to the submit handler, not the paste handler.
2. The TUI exits bracketed-paste mode within a bounded time after the paste ends, regardless of payload size.
3. Multiple submit gestures do not produce multiple paste events (the #N counter should not increment on a submit).

A small fix in the input state machine — distinguishing "submit during settling paste" from "new paste" — would resolve this without affecting normal interactive use.

Contact

• Submitter: Nicholas Francis O'Brien
• Email: nicko.obrien.ai@gmail.com
• GitHub: nicholasob7
• Website: https://nicko.obrienai.com

Happy to provide additional reproduction details, session logs, or testing on a candidate patch if helpful.