Replies: 46 comments 20 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Running Claude Code and Codex side by side. Ctrl+J feels impossible. Configurability would be awesome. |
Beta Was this translation helpful? Give feedback.
-
|
Yea Ctrl+J is a wild design choice. Makes codex fundamentally unusable right now. |
Beta Was this translation helpful? Give feedback.
-
|
Running codex inside tmux in Wezterm on Mac. Shift+Enter runs the command. Ctrl+J is my tmux prefix 🤦 |
Beta Was this translation helpful? Give feedback.
-
|
Really hoping this gets updated, I keep on accidentally submitting half-baked thoughts due to my shift+enter muscle memory. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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).
So a minimal settings.json could look like: |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Definitely change to Shift + Enter. |
Beta Was this translation helpful? Give feedback.
-
|
You can do this with Alt + Enter (on linux at least) |
Beta Was this translation helpful? Give feedback.
-
|
You can add a new line with Alt + Enter (on linux at least) |
Beta Was this translation helpful? Give feedback.
-
|
this is unbelievably stupid!! |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
What is status on this issue? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Alt + Shift + Enter works under windows |
Beta Was this translation helpful? Give feedback.
-
|
@TylonHH that maximizes the terminal window |
Beta Was this translation helpful? Give feedback.
-
|
For anyone digging into the root cause, this behavior is tracked upstream in Crossterm here: 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:
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-readIf 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. |
Beta Was this translation helpful? Give feedback.
-
|
Ghostty 1.2.3 (Build 12214) on macOS Sequoia |
Beta Was this translation helpful? Give feedback.
-
|
Iterm2 Build 3.6.7beta2 on macOS Sequoia |
Beta Was this translation helpful? Give feedback.
-
|
macOS + Tabby: crossterm keydump shows Shift+Enter is identical to Enter: Workaround: Karabiner‑Elements remap Shift+Enter → LF (Ctrl+J). Terminal‑agnostic; example below scopes it to Tabby via bundle id. Create rule file: {
"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”. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
This comment has been minimized.
This comment has been minimized.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment has been minimized.
This comment has been minimized.
-
|
for temp work around, thats least annoying w/o installing anything, I am mapping shift+down-arrow to |
Beta Was this translation helpful? Give feedback.
-
|
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 This behavior frequently causes unfinished Japanese text to be accidentally sent to Codex upon pressing Complicating this further is that the Codex extension's current behavior requires only When using an IME, we must constantly keep track of these combinations in our heads and instantly switch between Therefore, I'd like to request an option in VS Code to always send dialogs only with I realize this could be inconvenient for those not using an IME, so it would be good if it were configurable. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
How to do it when running codex in tmux in alacritty on a macbook? |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
-
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!
Beta Was this translation helpful? Give feedback.
All reactions