Shift + Enter Executes Command Instead of Creating a Newline in Integrated Terminal

[jskorlol]

Hi everyone,

I'm encountering a keybinding issue within the IntelliJ integrated terminal, specifically when I'm using an interactive CLI tool like codex.

My goal is to input a multi-line command. In many other terminal applications, pressing Shift + Enter inserts a newline, allowing me to continue writing the command on the next line.

However, when I press Shift + Enter inside the IntelliJ terminal, it behaves exactly like pressing Enter on its own—it immediately executes the current line as a command.

This makes it very difficult to work with multi-line inputs in tools that require them.

I've already looked through the Settings > Keymap to see if Shift + Enter is bound to a conflicting action, but I couldn't find anything obvious that targets the terminal specifically.

Has anyone else faced this issue? Is there a specific setting in IntelliJ's terminal configuration or a keymap override that I can apply to make Shift + Enter function as a simple newline character?

Any help or guidance would be greatly appreciated. Thank you!

[cdrx]

I dont think this is JetBrains specific. You'll see the same behaviour if you open codex via the MacOS Terminal app. The shortcut for a new line is ctrl-j.

I would love a way to change this because the muscle memory is strong.

[HaleTruman]

Especially when you bounce between gui chat and codex cli 😂

[mirumirumi]

same!

[parkie0517]

wow it works! thanks so much!

[balusch]

Same here! :)

[nkaijala]

Running Claude Code and Codex side by side. Ctrl+J feels impossible. Configurability would be awesome.

[zacharypodbela]

Yea Ctrl+J is a wild design choice. Makes codex fundamentally unusable right now.

[JohnAllen]

Unusable is too strong a word for this; I just started using it this way after being used to shift-Return/Enter.

[grepsedawk]

ctrl+j is set to go "down" one tmux pane. Is there no way to do newline without ctrl+j?

[flowerornament]

Running codex inside tmux in Wezterm on Mac. Shift+Enter runs the command. Ctrl+J is my tmux prefix 🤦

[birnam]

Ctrl-j is part of my tmux pane navigation and vim splits navigation (replacing [prefix]+j and C-w+j respectively). Having it for a newline is such a strange choice.

[mvattuone]

Try adding this keybinding to config.keys so Shift+Enter sends a newline.

{
  key = "Enter",
  mods = "SHIFT",
  action = wezterm.action.SendString "\x0a",
}

I haven't run into any conflicts or issues with my setup. 🤷

[albseb511]

damn i found out its control + J today.

[joshkellett87]

Really hoping this gets updated, I keep on accidentally submitting half-baked thoughts due to my shift+enter muscle memory.

[piotrborowian]

Please make it Shift + Enter, or configurable. Like everyone else here, I keep submitting half-baked messages which drives me insane. Don't fight our collective muscle memory; ctrl-j is a terrible choice IMHO.

[rwestwood89]

Agreed on it being a wild design decision. But if you are on WSL, here is a workaround that works for me. (And there are probably similar techniques for other terminals).

1. Edit the terminal settings.json

• In a terminal window, "ctrl+," and a window should pop up. Click "Open JSON file" in bottom left

2. Add a binding under "keybindings:"

        {
            "id": "User.sendLF",
            "keys": "shift+enter"
        },

3. Add an action for that keybinding under "actions":

        {
            "command": 
            {
                "action": "sendInput",
                "input": "\u000A"
            },
            "id": "User.sendLF"
        }

So a minimal settings.json could look like:

{
    "$help": "https://aka.ms/terminal-documentation",
    "$schema": "https://aka.ms/terminal-profiles-schema-preview",
    "actions": 
    [
        {
            "command": 
            {
                "action": "sendInput",
                "input": "\u000A"
            },
            "id": "User.sendLF"
        }
    ],
    "keybindings": 
    [
        {
            "id": "User.sendLF",
            "keys": "shift+enter"
        },
    ]
}
    
    

[Xavierus]

Same, love Codex, especially after new updates, but Ctrl + J feels like learning to play Piano. Please make it adjustable! Or change to Shift - Enter

[bleedingdev-quantum]

Definitely change to Shift + Enter.

[zuuxuux]

You can do this with Alt + Enter (on linux at least)

[entrity]

I was using this keybinding successfully until recently. I think they got rid of it.

[etraut-openai]

In CLI 0.128.0 we introduced /keymap as a way to customize any key binding in the TUI. As part of this feature work, we introduced a regression that affects Alt+Enter in some terminal apps. The bug is fixed on the main branch, and it will be included in 0.129.0. You can switch back to 0.127.0 in the meantime if this is affecting you. Or you can install the latest alpha (0.129.0-alpha.2) if you want to test out the bug fix. Apologies for any inconvenience.

[shanesparfuchs]

Funny that in /keymap shift+enter is there, but doesn't work. Might want to fix that one too. Also, still broken in alpha.2.

[microspino]

Same here, macos arm M2, ghostty.
0.129.0-alpha.2 it's broken too.

[zuuxuux]

You can add a new line with Alt + Enter (on linux at least)

[birnam]

I tried this one too, but in Windows Terminal that's the keybinding to toggle between windowed and full screen. I'm not sure if there's an override.

I realized my problem was my tmux keybindings. I have Ctrl + vim movements (h j k l) for changing panes in tmux and vim, so Ctrl-j is 'next pane down'. The terminal and/or tmux was converting my Ctrl-Enter and Shift-Enter attempts INTO a Ctrl-j, because it is ALSO the ASCII keycode for a newline. Which is why Ctrl-j is used here -- it's not some novel weird keybinding choice, it's actually just ASCII.

So for now I'm trying to find the best way to remove the Ctrl-j binding in tmux in panes that are running codex. It's not great though because the codex process is just node, and I run a lot of stuff with node, so my binding is off in a lot of panes now. I still need to work that one out.

But anway. This is the 'why'.

[mysehyunhope]

thanks, it is working on ubuntu wsl.

[timothy-web3-dev]

this is unbelievably stupid!!

[Jianhua-Cui]

I've been following this issue for three versions, but it still hasn't been fixed as of v0.47.0.

Apparently, they consider it a feature rather than a bug.

[wojtess]

What is status on this issue?

[ljara2106]

Was wondering about this too, im on a Mac - cant go to next line....should be configurable for us. or at least give us a shortcut.

[cdrx]

The shortcut for a new line is ctrl-j.

[ljara2106]

The shortcut for a new line is ctrl-j.

Ah yes CTRL + J works for mac, thank you sir.

[d4tocchini]

for temp work around, thats least annoying w/o installing anything, I am mapping shift+down-arrow to \012 (new line). at least its not ctrl+J

[kekyo]

I wasn't sure if I should post this here. Sorry if I'm wrong.

I use the Codex extension in VS Code, but I'm really tired of sending chat messages. I'm a Japanese-speaking developer and always use an IME (Input Method Editor) for keyboard typing.

The following explanation is for those unfamiliar with IMEs, so it's a bit lengthy:

---

An IME has a kind of buffer called an "intermediate editing state." Within this buffer, I temporarily edit alphabetically typed characters, convert them to Japanese, and finally input the Japanese text into the actual application.

This happens outside VS Code, supported by IME editing features like IBus or fcitx. When confirming Japanese from this intermediate state, we use the [Enter] key. Here's the problem: when the temporary buffer is empty, pressing [Enter] sends an [Enter] notification directly to the application. However, when the buffer contains alphabetic input, pressing [Enter] is consumed as part of the conversion process to Japanese and no [Enter] notification reaches the application.

This behavior frequently causes unfinished Japanese text to be accidentally sent to Codex upon pressing [Enter], forcing users to hastily cancel the attempt. I imagine similar issues occur when using IMEs with other languages.

Complicating this further is that the Codex extension's current behavior requires only [Enter] to initiate thinking for the first line of input, while requiring [Shift]+[Enter] for subsequent lines.

When using an IME, we must constantly keep track of these combinations in our heads and instantly switch between [Enter] and [Shift]+[Enter] while typing. I'm about to lose my mind.

---

Therefore, I'd like to request an option in VS Code to always send dialogs only with [Shift]+[Enter] (or other combination). Given how painful this is, making dialogs start exclusively with [Shift]+[Enter] is a very appealing trade-off.

I realize this could be inconvenient for those not using an IME, so it would be good if it were configurable.

[etraut-openai]

@kekyo, thanks for the suggestion. Could you please open a feature request in the issue tracker? We generally prioritize features based on community member upvotes on feature requests.

[joshka-oai]

See #3024 (reply in thread) for why Ctrl+J

[dhensen]

How to do it when running codex in tmux in alacritty on a macbook?

[mgray88]

This worked in wezterm, I'm sure you can figure out a similar keybinding in alacritty

[suparious]

• Yes. Codex CLI supports this in config.

Add this to ~/.codex/config.toml:

[terminal]
newline = "ctrl_m"

That makes Ctrl+M insert a newline instead of Ctrl+J.

[movy]

oh thanks man, I cannot believe we have to set it up manually. Just proves that devs who vibe code these tools do not use these tools themselves.

[qianyizhang]

for those who are using vscode variant IDE. i found this works
in keybindings.json

  {
        "key": "shift+enter",
        "command": "workbench.action.terminal.sendSequence",
        "args": {
            "text": "\u001b[200~\n\u001b[201~"
        },
        "when": "terminalFocus"
    }

ps: i got this by querying codex, which is sweet

[arbitraguer]

for anyone who uses Karabiner + iterm2, this works for me.

                    {
                        "description": "Shift+Enter to Ctrl+J",
                        "manipulators": [
                            {
                                "conditions": [
                                    {
                                        "bundle_identifiers": [
                                            "^com\\.googlecode\\.iterm2$"
                                        ],
                                        "type": "frontmost_application_if"
                                    }
                                ],
                                "from": {
                                    "key_code": "return_or_enter",
                                    "modifiers": {
                                        "mandatory": [
                                            "shift"
                                        ],
                                        "optional": [
                                            "any"
                                        ]
                                    }
                                },
                                "to": [
                                    {
                                        "key_code": "j",
                                        "modifiers": [
                                            "control"
                                        ]
                                    }
                                ],
                                "type": "basic"
                            }
                        ]
                    }

[anhdam2]

Actually, use /keymap in Codex CLI to rebind, worked for me.

[LukasWillin]

This is the anwser. Thank you!
It also lists the other bound shortcuts like "Alt + Enter", which works for me.

[timothe]

For the people lurking over here, if you're using Ghostty, this worked for me:

# ~/.config/ghostty/config
keybind = shift+enter=text:\n

Edit config, reload, you're done.

[ChenZhu-Xie]

[bindings]
keys = [
  { key = "m", with = "control", esc = " \u000a" },
]

in config.toml works for rio on windows.

note there's an extra space before \u000a

[hoodrichpirobo]

The key point is that there are two separate layers here:

1. What Codex is bound to do when it receives a key event.
2. What the terminal actually sends to Codex.

For Codex CLI/TUI, the built-in reliable newline shortcut is Ctrl+J because Ctrl+J is the ASCII line-feed/newline character. That is why it works even in terminals that do not report Shift+Enter as a distinct key.

In current Codex versions, the better fix is to use the keymap support:

/keymap

Then look for:

Editor -> insert_newline

and bind it to the key you want, for example shift-enter or alt-enter.

You can also configure it manually in ~/.codex/config.toml:

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

Important caveat: if IntelliJ’s integrated terminal sends Shift+Enter to Codex as plain Enter, Codex cannot distinguish them. In that case, a Codex keymap change alone will not help, because Codex never receives a real shift-enter event. You need to make the terminal send a newline/LF sequence for Shift+Enter.

For terminals that support this, map Shift+Enter to LF / Ctrl+J / \x0a.

Examples:

WezTerm:

{
  key = "Enter",
  mods = "SHIFT",
  action = wezterm.action.SendString("\x0a"),
}

Ghostty:

keybind = shift+enter=text:\n

VS Code terminal:

{
  "key": "shift+enter",
  "command": "workbench.action.terminal.sendSequence",
  "args": {
    "text": "\u000a"
  },
  "when": "terminalFocus"
}

Windows Terminal:

{
  "command": {
    "action": "sendInput",
    "input": "\u000A"
  },
  "id": "User.sendLF"
}

{
  "id": "User.sendLF",
  "keys": "shift+enter"
}

So the practical answer is:

• Try Ctrl+J first.
• On newer Codex versions, use /keymap and bind Editor -> insert_newline.
• If Shift+Enter still submits, the terminal is probably collapsing it to Enter; fix it in the terminal/IDE keybinding layer by sending LF (\x0a / \u000A / Ctrl+J).
• For IntelliJ specifically, this is likely a terminal-event issue rather than a normal IDE action keymap conflict. If IntelliJ cannot emit a distinct Shift+Enter or send LF from the integrated terminal, Codex cannot fix that from inside the TUI.