Shift+Enter is not recognized inside tmux because Codex does not enable modifyOtherKeys / Ext 2

Resolved 💬 3 comments Opened May 8, 2026 by odlove Closed May 10, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.129.0

What subscription do you have?

plus

Which model were you using?

_No response_

What platform is your computer?

_No response_

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

_No response_

What issue are you seeing?

Problem

Inside tmux, Shift+Enter is received by Codex as plain Enter, so it submits instead of inserting a newline.

The same terminal/tmux setup works in Neovim.

Environment

  • Terminal: kitty 0.46.2
  • tmux: 3.6a
  • tmux config:
  • extended-keys on
  • extended-keys-format csi-u
  • xterm-keys on
  • terminal-features includes xterm*:extkeys
  • Codex: codex-cli 0.129.0

Reproduction

  1. Start Codex inside tmux.
  2. Run /keymap debug.
  3. Press Shift+Enter.
  4. Codex reports plain Enter / no shift modifier.
  5. tmux reports the Codex pane as VT10x.

Commands used:

tmux list-panes -a -F '#{pane_id} #{pane_current_command} #{pane_key_mode}'

Observed:

%0 codex VT10x

Compare with Neovim in the same tmux server:

%3 nvim Ext 2

Workaround / validation

Manually enabling xterm modifyOtherKeys mode 2 for the Codex pane fixes it:

printf '\e[>4;2m' > /dev/pts/0

After that, the Codex pane changes to Ext 2, and Shift+Enter is reported correctly.

Suspected cause

Codex currently enables crossterm/kitty keyboard enhancement in
codex-rs/tui/src/tui/keyboard_modes.rs:

pub(super) fn enable_keyboard_enhancement() {
    if keyboard_enhancement_disabled() {
        return;
    }

    let _ = execute!(
        stdout(),
        PushKeyboardEnhancementFlags(
            KeyboardEnhancementFlags::DISAMBIGUATE_ESCAPE_CODES
                | KeyboardEnhancementFlags::REPORT_EVENT_TYPES
                | KeyboardEnhancementFlags::REPORT_ALTERNATE_KEYS
        )
    );
}

but it does not send xterm/tmux modifyOtherKeys mode 2:

ESC [ > 4 ; 2 m

Codex already sends the corresponding reset on exit in
codex-rs/tui/src/tui/keyboard_modes.rs:

pub(super) fn reset_keyboard_reporting_after_exit() {
    let _ = execute!(
        stdout(),
        PopKeyboardEnhancementFlags,
        ResetKeyboardEnhancementFlags,
        DisableModifyOtherKeys
    );
}

impl Command for DisableModifyOtherKeys {
    fn write_ansi(&self, f: &mut impl fmt::Write) -> fmt::Result {
        f.write_str("\x1b[>4;0m")
    }
}
ESC [ > 4 ; 0 m

via DisableModifyOtherKeys, but there is no matching enable path.

Expected behavior

Codex should request an extended key mode compatible with tmux so Shift+Enter is distinguishable from Enter.

Related

What steps can reproduce the bug?

/

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #21213

Powered by Codex Action

matkozak · 3 months ago

I would like to chime in and say that despite numerous closed duplicates, this is a genuine issue and still present in 0.129.0.

Shift+Enter works for me everywhere except for tmux. The reason is that Codex is not getting the extended key sequence at all... because it is not requesting it.

The problem can be worked around by setting the relevant config: tmux set -s extended-keys always. But it would be preferable if Codex did it the right way (Claude Code does).

fcoury-oai contributor · 3 months ago
I would like to chime in and say that despite numerous closed duplicates, this is a genuine issue and still present in 0.129.0. Shift+Enter works for me everywhere except for tmux. The reason is that Codex is not getting the extended key sequence at all... because it is not requesting it. The problem _can_ be worked around by setting the relevant config: tmux set -s extended-keys always. But it would be preferable if Codex did it the right way (Claude Code does).

Totally agree, we have a fix coming on the PR above.