Codex TUI prompt Feature: Shift+Enter to support newline in codex interactive prompt

@etraut-openai, feel free to lmk about my proposal! Im super excited to contribute! :)

Codex needs to run in many different terminal emulators and across multiple platforms. Earlier versions of Codex supported Shift+Enter, but this caused problems with many terminal emulators. After investigating potential solutions, we switched to Ctrl+J as the key binding for entering newlines. This works across all terminals and platforms.

bring back shift + enter! ctrl+j is annoying

Also feeling the same way, but this also applied in Claude Code CLI. Hopefully, they would bring back in future! :))

Lmk what u guys think of the below feat as well, @SocialNerd42069 and @faev999!

https://github.com/openai/codex/issues/8709

bring back shift + enter! ctrl+j is annoying

we should at least be able to choose between the two (or have both ideally). maybe allowing for custom keybindings would help a lot here.

<img width="1156" height="314" alt="Image" src="https://github.com/user-attachments/assets/f85e42f5-fb39-42f0-bd3b-8f36d49ce403" />

shift+enter is also still highlighted as the command still when using ? to show the shortcuts (using TUI2).

Codex needs to run in many different terminal emulators and across multiple platforms. Earlier versions of Codex supported Shift+Enter, but this caused problems with many terminal emulators. After investigating potential solutions, we switched to Ctrl+J as the key binding for entering newlines. This works across all terminals and platforms.

That's fair enough, keep Ctrl+J as the default.

Please add the option to change newline to Shift + Enter for those of us who's terminals emulators allow us to do that.

Avoid Control Button Please!

If supporting Shift+Enter is difficult, then please consider Option+Enter or Command+Shift+Enter instead. Ctrl+J is a really poor choice.
What happens if, for some reason, the same developer ends up using Codex on both Ubuntu and macOS in the future?
At the very least, Command+J would be a better option.
The Ctrl key is disliked by many macOS users :)

I just paid for the subscription. I can't believe this is the key binding! ctrl+j for me is down arrow because of vim bindings. who chooses these things?

@etraut-openai please make this mappable.. ctrl-j is not tmux friendly

Can we please just get back shift+enter? Or make the broken terminals fix it via /keymap? Why break most of your existing users?

It would be great if this was configurable in config.toml.

Ctrl+J is very counter intuitive, at least consider Ctrl+Enter

Quick note from a deeper dive on the Windows Terminal angle of this — there's a Windows-specific manifestation that's slightly different from what's been discussed.

I ran crossterm's key-event capture on Windows Terminal pressing Shift+Enter, plain Enter, Ctrl+J, Ctrl+M, and Ctrl+Enter. Result:

| Keypress | crossterm event |
|---|---|
| Shift+Enter | KeyCode::Enter + CONTROL |
| Ctrl+Enter | KeyCode::Enter + CONTROL ← identical |
| Plain Enter | KeyCode::Enter (no mods) |
| Ctrl+J | KeyCode::Char('j') + CONTROL |
| Ctrl+M | KeyCode::Char('m') + CONTROL |

Two takeaways:

1. Windows Terminal collapses Shift+Enter and Ctrl+Enter into the same event at the OS console layer. That's a Windows console limitation, can't be undone from codex's side.
2. None of the existing insert_newline defaults match KeyCode::Enter + CONTROL — defaults check Char('j')+CTRL, Char('m')+CTRL, plain Enter, shift Enter, alt Enter. So the actual event Windows Terminal delivers matches none of them, and the keystroke either submits (via composer's submit_keys) or gets eaten depending on context.

This explains why the ~/.codex/config.toml workaround circulating in #4218 and elsewhere (insert_newline = ["ctrl-j", "ctrl-m", "enter", "shift-enter", "alt-enter"]) doesn't reliably help on Windows Terminal: it's identical to the defaults. None of the bindings in that list catch the actual Enter+CONTROL event.

@joshka-oai's observation in #3024 is exactly right — many terminals collapse Shift+Enter into other signals. Ctrl+J is the official cross-platform answer. This patch is consistent with that pattern; it just adds Enter+CONTROL (Windows Terminal's collapsed event) to the same set that Ctrl+J already lives in.

Proposed fix

Branch: https://github.com/jacobhallgren/codex/tree/fix/win-shift-enter

codex-rs/tui/src/keymap.rs:

1. Add ctrl(KeyCode::Enter) to editor.insert_newline defaults under #[cfg(windows)]. Catches both Shift+Enter and Ctrl+Enter on Windows Terminal (they're indistinguishable anyway). Linux/macOS unchanged — shift(KeyCode::Enter) already handles those via the kitty protocol.
2. Extend the existing validate_no_shadow allowed_overlaps list with the same key/action pair, so users who rebind composer.submit = ctrl-enter (per #5716) still pass the runtime conflict check. This mirrors the existing entry that already permits plain Enter to live in both composer.submit and editor.insert_newline.

Diff size: 1 file, 59 insertions, 22 deletions. Targeted tests pass: cargo test -p codex-tui --lib keymap (95/95).

On the broader picture

This is one of (at least) three different platform-specific manifestations of the same surface symptom; each needs its own targeted fix:

• Linux/macOS without a multiplexer: kitty protocol works, existing shift(KeyCode::Enter) matches. ✓
• tmux: codex doesn't enable modifyOtherKeys mode 2 (\x1b[>4;2m), so tmux strips the SHIFT modifier. See the analysis at #21699 — @fcoury-oai mentioned a fix is in flight there.
• Windows Terminal: even with kitty protocol enabled, Shift+Enter is delivered as Enter+CTRL (Windows console quirk). My branch above addresses this one.

Happy to open a PR per CONTRIBUTING.md if a maintainer wants to invite. Otherwise the branch is public and the diff is small enough to be picked up under another author if that fits the workflow better.

The keybinding for this action is now editable. You can use /keymap to assign whatever keybinding you prefer. This allows you to select a binding that's compatible with your terminal emulator.