Provide a practical submit binding when Enter inserts a newline
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_
1 Comment
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.