Make ENTER insert newline in Codex TUI input (send on Ctrl+Enter instead)

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

• #11559
• #10209

Powered by Codex Action

Neither of them are duplicates of what is requested here.

It would be nice, at least, to have these as configurable settings.

this is how all the CLIs work. I personally prefer it the way it is.

Shift+Enter is the standard on CLI tools for newline, but every terminal does handle it a bit differently.

@am-will shift+enter doesn’t add new line in codex CLI.
The only that does is ctrl+j

I’d be fine with shift+enter!

@am-will shift+enter doesn’t add new line in codex CLI. The only that does is ctrl+j I’d be fine with shift+enter!

It's Terminal dependent. What are you using?

Macs Terminal App

+1 much needed

Shift + Enter makes sense for new line??

I researched this a bit and actually, it is just plain implausible in some terminals or possibly in all.

While it _makes sense_ for those of us who do not "come" from a terminal world, a vim nerd would kill us for saying that, because no, new line is ctrl + j and enter is submit and that's it (for them). Well. They also grow beards and like to type typos to correct with fk but whatever 🤣

Thing is, _preferences aside_, its just impossible sending a shift key modifier to a _terminal_, it is usually hijacked by the app level (similar as cmd on a Mac can never be sent to the terminal, only to the wrapping app).

It might as such simply be impossible to achieve what was asked for here :(

Please make it configurable, for clients that use both ChatGPT and codex, i.e. all your clients, this is extremely frustrating as in ChatGPT we have to press Shift+Enter for a new line and in codex Ctrl+J.

It feels like every 10 minutes I have to stop a run because my prompt was not done yet, I just pressed shift+Enter from muscle memory and in codex world that means ENTER not new line... making me pull my hear out at a product that is otherwise absolutely amazing!

@gertsteyn see my previous comment, its not necessarily "codex world" but rather "terminal world".

For solving the issue on my end I use ctrl+G, it opens it in your defined code editor, which allows you to write prompt there and then save + close said temp file, which puts it automatically into the prompt area of CLI.

That avoids the rather nerdy ctrl+j.

Macs Terminal App

Be that as it may, enter is never newline in any other tui agent so that would be highly disruptive imo.

Every terminal handles newline differently and I sympathize with how annoying that may be, but enter should remain send for sure.

Try control+enter? One of them should work.

I think the common thread here is some mechanism that allows customisation. E.g. like in slack and many other chat based apps where you can choose if submit must be enter or Ctrl+Enter or anything else if the user wanted to.

If some options like Shift is not available because of terminal limitations then so be it, but at least give power users the option to customise with what is available.

After-all someone decided that TAB should be SUBMIT, but Ctrl+Enter must not be allowed??

@am-will
Yes, as you can see that was widely clarified already after your comment, thanks!

On Mac at least, you can't do ctrl + enter either. _Perhaps_ one could mess with system keyboard binding but that is too much of a customization even if possible, just to fix something that can be easily worked around by using ctrl+G (open editor).

I personally feel this ticket could be indeed closed, because it is just not really feasible to do much customizations apparently in a terminal.
Happy thou to leave it open for if the team at OAI is willing to look at options.

@smileBeda The open editor is not a real solution as you then loose other crutial functionality like the @ file auto completion.

FYI: The coding agent from the other side of the aisle already went through this episode and resolved it:

_

Shift+Enter works without configuration in iTerm2, WezTerm, Ghostty, and Kitty. For other terminals (VS Code, Alacritty, Zed, Warp), run /terminal-setup to install the binding.

_

https://code.claude.com/docs/en/interactive-mode

@am-will Yes, as you can see that was widely clarified already after your comment, thanks! On Mac at least, you can't do ctrl + enter either. _Perhaps_ one could mess with system keyboard binding but that is too much of a customization even if possible, just to fix something that can be easily worked around by using ctrl+G (open editor). I personally feel this ticket could be indeed closed, because it is just not really feasible to do much customizations apparently in a terminal. Happy thou to leave it open for if the team at OAI is willing to look at options.

For sure. I'd love to see more customization for you though. Cheers

A lot of this is possible today through the configurable TUI keymap.

For the “editor-style” behavior where Enter inserts a newline and Ctrl+Enter submits, you can configure:

[tui.keymap.composer]
submit = "ctrl-enter"

editor.insert_newline already includes plain enter by default, so once composer.submit no longer owns plain Enter, pressing Enter will insert a newline.

A fuller explicit version would be:

[tui.keymap.composer]
submit = "ctrl-enter"

[tui.keymap.editor]
insert_newline = ["enter", "shift-enter", "ctrl-j", "ctrl-m", "alt-enter"]

What this does not provide yet is a first-class preset like terminal-style vs editor-style, or Cmd+Enter as a portable keymap modifier. So the current answer is “yes via keymap config for Ctrl+Enter,” but not yet as a one-line UX mode.

Regarding the Cmd+Enter request, the tricky part is that Cmd is not something terminal apps generally pass through to terminal programs as a normal, portable modifier the way Ctrl, Alt, or Shift can be reported.

On macOS, Cmd is usually handled by the terminal emulator or host app itself for window/menu shortcuts. Some terminals can be configured to catch a Cmd shortcut and send a custom byte sequence to the shell, but that is terminal-specific configuration rather than something Codex can rely on natively across terminals.

Today, the portable Codex-side option is to bind submit to something like Ctrl+Enter:

[tui.keymap.composer]
submit = "ctrl-enter"

Then users who want Cmd+Enter can often configure their terminal to translate Cmd+Enter into whatever sequence their terminal sends for Ctrl+Enter, or into another sequence Codex already understands.

For example, in terminals such as WezTerm, Ghostty, Alacritty, kitty, iTerm2, or VS Code’s integrated terminal, this is typically possible through a custom keybinding that sends text / an escape sequence to the terminal process. The exact syntax differs by terminal, so we probably should not document one universal Cmd+Enter binding as if it works everywhere.

So I think the solution here would be:

• Codex should continue to offer portable keymap actions like ctrl-enter, shift-enter, alt-enter, etc.
• Advanced users can map Cmd+Enter at the terminal-emulator layer to one of those portable bindings.
• We should avoid making Cmd+Enter a default Codex binding unless we add and validate first-class cmd / super keymap support across the major macOS terminals.

If this setup covers your workflow, would you mind closing the issue?

I am closing this issue, but if you find it still doesn't work, feel free to leave a comment and I'll reopen it.

@fcoury-oai - sorry for the delayed reply.

Even though things are different in 0.130.0, it’s still basically impossible to map Shift+Enter (or honestly any sane keybinding) in the Mac Terminal.app in a way that makes these features behave correctly and not break other keybindings.

And this isn’t even Codex's fault. It's apparently just a feature limitation of a $2000 machine made by a company whose entire brand is "it just works".

I finally gave up fighting it and installed Ghostty. Zero config. Works immediately.

Really makes you reflect on life choices. But I guess the divorce-inciting software running on beautiful hardware tradeoff is still somehow better than the alternatives.

Jeez. What a deeply committed fanboy idiot I am.

<img width="1254" height="1254" alt="Image" src="https://github.com/user-attachments/assets/64fd70db-aa4f-42ce-aee9-aa2e8302760a" />