What version of Codex CLI is running?
codex-cli 0.157.0
What subscription do you have?
Not relevant to terminal input handling.
Which model were you using?
Not relevant; the problem is in the TUI composer.
What platform is your computer?
Ubuntu 24.04.4 LTS, Linux 6.17.0-122035-tuxedo x86_64 x86_64, Wayland (XDG_SESSION_TYPE=wayland).
What terminal emulator and version are you using?
shitty, standalone Wayland terminal, release 15 (st-linux-x86_64.tar.gz). A local script named st launches the installed binary. No tmux or other multiplexer in the affected session.
Codex doctor report
Not attached; the report was not needed to identify the terminal input path.
What issue are you seeing?
After updating to 0.157.0, middle-clicking to paste the Wayland primary selection into the Codex CLI composer no longer inserts text. The user reports that shitty was unchanged and this worked before updating Codex to 0.157.0. This is distinct from Ctrl+V or clipboard paste.
What steps can reproduce the bug?
- On Wayland in
shitty, select text so it is available as the primary selection.
- Start
codex 0.157.0 with its default TUI settings in a terminal supporting middle-click paste.
- Middle-click inside the composer.
The report comes from an interactive user session; I could inspect the configuration and source, but could not automate a physical middle-click reproduction or run a controlled 0.156.1 comparison.
What is the expected behavior?
The selected text is inserted into the composer, as it was before the update.
Additional information
Installed terminal provenance: SHA-256 of /home/ei-grad/.local/libexec/shitty is c302a2543dae5979adb26619362477315a9a1c0b2c5b5dba66c895eb4002caa9, identical to the st member of release 15's st-linux-x86_64.tar.gz. gh attestation verify succeeded for that archive against pg83/shitty, with signer https://github.com/pg83/shitty/.github/workflows/release.yml@refs/heads/master. The archive digest is 2fbeb73f3a88165ce10bab2880b42beb38de61d2f666a0079f7710bdbeea96a1. The installed file was last modified on 2026-09-02.
The local [tui] configuration does not set fullscreen_transcript. PR #47178 changed its default to true in 0.157.0. In the resulting owned alternate-screen mode, OverlayInput::Default captures the mouse; AlternateScreen::configure_input enables terminal mouse reporting (?1000, ?1002, ?1006, ?1003). The terminal's source confirms the consequence: with mouse reporting active, VtermInput::pointerButton sends the button event to the application and returns before reaching its middle-button paste(true) branch. MouseFrontendState::protocolActive makes Shift bypass mouse reporting. Thus Codex's new default, rather than a change in shitty, diverts an unmodified middle click from shitty's native Wayland primary-selection paste path. Sources: #47178, https://github.com/openai/codex/blob/rust-v0.157.0/codex-rs/tui/src/tui/alternate_screen.rs, https://github.com/pg83/shitty/blob/bfe3b41cd980b425a8e30263c69d110054f09ff6/lib/shitty/vterm.cpp, and https://github.com/pg83/shitty/blob/bfe3b41cd980b425a8e30263c69d110054f09ff6/lib/shitty/mouse_frontend.cpp.
An explicit -c tui.fullscreen_transcript=false, --no-alt-screen, or Shift+middle-click may be a temporary workaround; none has yet been verified by a click test. A useful fix would preserve middle-click primary-selection paste while fullscreen transcript is active.
Prepared with LM assistance — Codex CLI
What version of Codex CLI is running?
codex-cli 0.157.0What subscription do you have?
Not relevant to terminal input handling.
Which model were you using?
Not relevant; the problem is in the TUI composer.
What platform is your computer?
Ubuntu 24.04.4 LTS,
Linux 6.17.0-122035-tuxedo x86_64 x86_64, Wayland (XDG_SESSION_TYPE=wayland).What terminal emulator and version are you using?
shitty, standalone Wayland terminal, release 15 (st-linux-x86_64.tar.gz). A local script namedstlaunches the installed binary. No tmux or other multiplexer in the affected session.Codex doctor report
Not attached; the report was not needed to identify the terminal input path.
What issue are you seeing?
After updating to 0.157.0, middle-clicking to paste the Wayland primary selection into the Codex CLI composer no longer inserts text. The user reports that
shittywas unchanged and this worked before updating Codex to 0.157.0. This is distinct from Ctrl+V or clipboard paste.What steps can reproduce the bug?
shitty, select text so it is available as the primary selection.codex0.157.0 with its default TUI settings in a terminal supporting middle-click paste.The report comes from an interactive user session; I could inspect the configuration and source, but could not automate a physical middle-click reproduction or run a controlled 0.156.1 comparison.
What is the expected behavior?
The selected text is inserted into the composer, as it was before the update.
Additional information
Installed terminal provenance: SHA-256 of
/home/ei-grad/.local/libexec/shittyisc302a2543dae5979adb26619362477315a9a1c0b2c5b5dba66c895eb4002caa9, identical to thestmember of release 15'sst-linux-x86_64.tar.gz.gh attestation verifysucceeded for that archive againstpg83/shitty, with signerhttps://github.com/pg83/shitty/.github/workflows/release.yml@refs/heads/master. The archive digest is2fbeb73f3a88165ce10bab2880b42beb38de61d2f666a0079f7710bdbeea96a1. The installed file was last modified on 2026-09-02.The local
[tui]configuration does not setfullscreen_transcript. PR #47178 changed its default totruein 0.157.0. In the resulting owned alternate-screen mode,OverlayInput::Defaultcaptures the mouse;AlternateScreen::configure_inputenables terminal mouse reporting (?1000,?1002,?1006,?1003). The terminal's source confirms the consequence: with mouse reporting active,VtermInput::pointerButtonsends the button event to the application and returns before reaching its middle-buttonpaste(true)branch.MouseFrontendState::protocolActivemakes Shift bypass mouse reporting. Thus Codex's new default, rather than a change inshitty, diverts an unmodified middle click fromshitty's native Wayland primary-selection paste path. Sources: #47178, https://github.com/openai/codex/blob/rust-v0.157.0/codex-rs/tui/src/tui/alternate_screen.rs, https://github.com/pg83/shitty/blob/bfe3b41cd980b425a8e30263c69d110054f09ff6/lib/shitty/vterm.cpp, and https://github.com/pg83/shitty/blob/bfe3b41cd980b425a8e30263c69d110054f09ff6/lib/shitty/mouse_frontend.cpp.An explicit
-c tui.fullscreen_transcript=false,--no-alt-screen, or Shift+middle-click may be a temporary workaround; none has yet been verified by a click test. A useful fix would preserve middle-click primary-selection paste while fullscreen transcript is active.Prepared with LM assistance — Codex CLI