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 😂

[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.

[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. 🤷

[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)

[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.

[TylonHH]

Alt + Shift + Enter works under windows

[AntonioCS]

@TylonHH that maximizes the terminal window

[joshka-oai]

For anyone digging into the root cause, this behavior is tracked upstream in Crossterm here:
crossterm-rs/crossterm#685

Just for context, Crossterm is a small, maintainer-driven project and I also help maintain it in my own time. That issue already captures the problem space well, so if you head over there, what is most helpful is concrete data (for example what key events your terminal actually sends), rather than +1s or duplicate reports.

Keeping the signal high there makes it much more likely we can actually improve things for everyone.

The important bit: Ctrl+J isn’t an arbitrary shortcut. It corresponds to the ASCII control code for newline (LF). Many terminals do not reliably produce a distinct “Shift+Enter” (or “Ctrl+Enter”) key event, and in some environments those combinations collapse into the same underlying newline signal.

That leaves a few practical paths forward:

1. Improve Crossterm so it can preserve more of these key combinations across terminals (where the terminal actually sends something distinguishable).
2. Capture real behavior across terminals + multiplexers and ship sensible defaults per environment (terminal + tmux/zellij can matter a lot here).
3. Make it configurable so users can pick a newline insertion binding that doesn’t conflict with their setup (tmux pane navigation via Ctrl+J is a common conflict).

Some combination of these is likely the right long-term answer.

We can’t realistically cover every terminal in existence (there’s a long tail), but we do test regularly on the major ones (VS Code, Terminal.app, iTerm2, Ghostty; and when possible Windows Terminal, plus sometimes Kitty/Alacritty/WezTerm).

If you want to see exactly what your terminal is sending for Shift+Enter / Ctrl+Enter, Crossterm includes a tiny event viewer:

gh repo clone crossterm-rs/crossterm
cd crossterm
cargo run --example event-read

If folks are willing, it would be extremely helpful to build a community list of these outputs including terminal + OS + whether you’re in tmux/zellij. That data is what lets us decide whether Shift+Enter can be supported reliably, whether we need per-terminal defaults, and what configuration knobs make sense.

I’ll start by posting Ghostty results below.

Note: this should mostly be around testing what characters shift+enter produces.

[joshka-oai]

Ghostty 1.2.3 (Build 12214) on macOS Sequoia

gh repo clone crossterm-rs/crossterm; cd crossterm; cargo run --example event-read

Event: Key(KeyEvent { code: Modifier(LeftShift), modifiers: KeyModifiers(SHIFT), kind: Press, state: KeyEventState(0x0) })
Event: Key(KeyEvent { code: Enter, modifiers: KeyModifiers(SHIFT), kind: Press, state: KeyEventState(0x0) })
Event: Key(KeyEvent { code: Enter, modifiers: KeyModifiers(SHIFT), kind: Release, state: KeyEventState(0x0) })
Event: Key(KeyEvent { code: Modifier(LeftShift), modifiers: KeyModifiers(SHIFT), kind: Release, state: KeyEventState(0x0) })
Event: Key(KeyEvent { code: Esc, modifiers: KeyModifiers(0x0), kind: Press, state: KeyEventState(0x0) })

[dnwe]

Ghostty 1.2.3 (Build 12214) on macOS Sequoia running within tmux doesn't seem to register the key modifier for me:

% cargo run --example event-read
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.15s
     Running `target/debug/examples/event-read`
Blocking read()
 - Keyboard, mouse, focus and terminal resize events enabled
 - Hit "c" to print current cursor position
 - Use Esc to quit

Event: Key(KeyEvent { code: Enter, modifiers: KeyModifiers(0x0), kind: Press, state: KeyEventState(0x0) })

[duckworth]

Iterm2 Build 3.6.7beta2 on macOS Sequoia

Event: Key(KeyEvent { code: Modifier(LeftShift), modifiers: KeyModifiers(SHIFT), kind: Press, state: KeyEventState(0x0) })
Event: Key(KeyEvent { code: Enter, modifiers: KeyModifiers(SHIFT), kind: Press, state: KeyEventState(0x0) })
Event: Key(KeyEvent { code: Enter, modifiers: KeyModifiers(SHIFT), kind: Release, state: KeyEventState(0x0) })
Event: Key(KeyEvent { code: Modifier(LeftShift), modifiers: KeyModifiers(SHIFT), kind: Release, state: KeyEventState(0x0) })
Event: Key(KeyEvent { code: Esc, modifiers: KeyModifiers(0x0), kind: Press, state: KeyEventState(0x0) })

[joshka-oai]

That's a really odd result. I'd be curious about your settings that you're seeing both shift+enter and ctrl+j for the one keystroke there. Can't repro on the stable version of iTerm2.

Event: Key(KeyEvent { code: Modifier(RightShift), modifiers: KeyModifiers(SHIFT), kind: Press, state: KeyEventState(0x0) })
Event: Key(KeyEvent { code: Enter, modifiers: KeyModifiers(SHIFT), kind: Press, state: KeyEventState(0x0) })
Event: Key(KeyEvent { code: Enter, modifiers: KeyModifiers(SHIFT), kind: Release, state: KeyEventState(0x0) })
Event: Key(KeyEvent { code: Modifier(RightShift), modifiers: KeyModifiers(SHIFT), kind: Release, state: KeyEventState(0x0) })
Event: Key(KeyEvent { code: Esc, modifiers: KeyModifiers(0x0), kind: Press, state: KeyEventState(0x0) })

[duckworth]

updated, I had a binding in there to try and work around this issue.

[joshka-oai]

Got it - makes sense. You had me looking at release notes to see if iTerm2 had changed something in the beta :)

[tobiase]

macOS + Tabby: crossterm keydump shows Shift+Enter is identical to Enter:

KeyEvent { code: Enter, modifiers: KeyModifiers(0x0), kind: Press, state: KeyEventState(0x0) }
KeyEvent { code: Enter, modifiers: KeyModifiers(0x0), kind: Press, state: KeyEventState(0x0) }

Workaround: Karabiner‑Elements remap Shift+Enter → LF (Ctrl+J). Terminal‑agnostic; example below scopes it to Tabby via bundle id.

Create rule file: ~/.config/karabiner/assets/complex_modifications/tabby-shift-enter.json

{
  "title": "Tabby: Shift+Enter -> Ctrl+J",
  "rules": [
    {
      "description": "Tabby: Shift+Enter sends LF (Ctrl+J)",
      "manipulators": [
        {
          "type": "basic",
          "from": {
            "key_code": "return_or_enter",
            "modifiers": { "mandatory": ["shift"], "optional": ["any"] }
          },
          "to": [{ "key_code": "j", "modifiers": ["control"] }],
          "conditions": [
            {
              "type": "frontmost_application_if",
              "bundle_identifiers": ["^org\\.tabby$"]
            }
          ]
        }
      ]
    }
  ]
}

Enable: Karabiner‑Elements → Complex Modifications → Add rule → “Tabby: Shift+Enter -> Ctrl+J”.
To use another terminal, change the bundle id (or remove the condition for global).

[nazreen]

The funny thing:

you can solve this by having Claude Code installed, then in the terminal where you want to set up the keybinding for Shift + Enter, just run claude , then /terminal-setup. The keybinding would then be applied to Codex. Codex should really make it as easy as Claude Code makes it.

[mgray88]

🙏🏻 Nicely figured out. Worked for me on MacOS/Wezterm/tmux:

  -- wezterm config
  {
    key = "Enter",
    mods = "SHIFT",
    action = action.SendString("\x1b\r"),
  }

[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