Provide a practical submit binding when Enter inserts a newline

Open 💬 1 comment Opened Aug 2, 2026 by cfischer1967

What version of Codex CLI is running?

codex-cli 0.146.0

What subscription do you have?

Pro

Which model were you using?

Sol (does not matter)

What platform is your computer?

Ubuntu on Dell laptop; Linux 6.17.0-40-generic x86_64 x86_64

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

xterm/noble,now 390-1ubuntu3 amd64

Codex doctor report

What issue are you seeing?

Codex allows me to configure Enter to insert a line break, but this leaves no
practical key for submitting the prompt. My xterm does not distinguish Enter,
Ctrl-Enter, and Shift-Enter, while Alt-Enter is intercepted by the operating
system.

I currently use F5, but on many laptops that requires Fn plus a touch-style
function key and is awkward for frequent use. This is a common terminal
limitation.

Please provide an alternative submit mechanism that works reliably in
traditional terminals—for example, a configurable two-key sequence such as
Ctrl-X followed by Enter.

I understand that Windows users are used to Ctrl-X etc. in the Windows bindings but Unix users (Emacs and vi) have other habits. In particular when writing long prompts, accidental Enter that submits is an absolute nuisance.

What steps can reproduce the bug?

Uploaded thread: 019fbba2-f3b5-7e01-b520-d2ea80377932

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

1 Comment

cfischer1967 · 25 days ago

Codex already enters raw mode and has scoped support for xterm
modifyOtherKeys mode 2 (CSI > 4;2 m), with corresponding cleanup using
CSI > 4;0 m (\e[>4;2m or 0m). However, it currently enables that mode only
for tmux sessions reporting extended-keys-format csi-u; an ordinary xterm
instead receives the Kitty/CSI-u keyboard-enhancement request, which
xterm does not necessarily support. Could Codex detect xterm and enable
modifyOtherKeys mode 2 for the lifetime of the TUI, restoring mode 0 on
suspension and exit? This would distinguish Ctrl-Enter without requiring
a harmful global X resource.