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.