›_ Codex Issues
Codex Issues / #4218

Regression: Shift+Enter sends prompt instead of inserting line break (macOS)

Open 💬 16 comments Opened Sep 25, 2025 by sutaminajing40
💡 Likely answer: A maintainer (fcoury, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

v0.41.0

Which model were you using?

gpt-5-codex

What platform is your computer?

Darwin 24.5.0 arm64 arm

What steps can reproduce the bug?

Hi, it looks like the issue described in #545 has reappeared.

Previously, Shift+Enter worked correctly and inserted a line break.
In the current latest version, however, pressing Shift+Enter sends the prompt instead of inserting a line break.

Environment

  • OS: macOS

Steps to reproduce

  1. Type some text in the prompt field.
  2. Press Shift+Enter.
  3. Instead of inserting a line break, the prompt is submitted.

Expected behavior
Shift+Enter should insert a line break, not submit the prompt.

This used to work until recently, so it appears to be a regression.

What is the expected behavior?

_No response_

What do you see instead?

_No response_

Additional information

_No response_

View original on GitHub ↗

16 Comments

duckSquirrelPilot · 9 months ago

This happens for me too sometimes. Usually it's fixed if I quit and restart codex, so there's something buggy about the UI

azogue · 9 months ago
so there's something buggy about the UI

something related to the terminal settings?

With 0.41, I see ctr+J in pycharm's terminal, but I have shift+enter in ghostty, at the same time 🫠
(brew install in macOS, just updated, for new codex instantiations)

wintercounter · 9 months ago

Same in Windows Terminal.

Jianhua-Cui · 9 months ago

Same in macOS with Cursor, using codex version v0.42.0

richard-vock · 9 months ago

Also broken on NixOS in version 0.42.0.

yipu3 · 8 months ago

Same on macOS terminal.
cli version: codex-cli 0.50.0
macOS version: 15.7.1

rsyring · 8 months ago

This issue is for macOS but I'd like Shift+Enter to work on Linux as well. Is that a separate issue or is it supposed to work on Linux and isn't?

tkellogg · 8 months ago

I'm on 0.53.0 on MacOS and it seems to work fine in iTerm2 but fails in Cursor.

angelcervera · 7 months ago

Same in Linux Ubuntu. Please fix it.

lu-zero · 7 months ago

Seems to fail consistently in wezterm as well.

fcoury contributor · 5 months ago

If you are using Ghostty you can mitigate this issue by adding this to your config:

keybind = shift+enter=text:\x1b\r
zenbo · 4 months ago

I can reproduce a very similar issue on macOS, but with Tab.

For me, pressing Tab submits the prompt instead of performing a non-submit action.
This reproduces:

  • in iTerm2
  • in Terminal.app
  • even when tmux is not running

This is a regression. It did not happen in codex@0.98.0, and I have been seeing it consistently in versions after that.

This may be part of the same macOS terminal key-handling regression family as this issue.

nailo2c · 2 months ago

I can reproduce this on macOS with Codex CLI v0.128.0.

In my case, Shift+Enter no longer inserts a newline and instead submits the prompt.
After downgrading to v0.125.0, Shift+Enter works again as expected.

Environment:

  • OS: macOS
  • Codex CLI: v0.128.0
  • Previous working version: v0.125.0
  • Terminal: VSCode terminal
kimdwkimdw · 2 months ago

current workaround, in ~/.codex/config.toml, Add this

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

remove shift+enter, add "alt-enter"

@nailo2c

fcoury-oai contributor · 2 months ago

If you are still suffering from this bug, please first run /keymap debug and press Shift+Enter to check what your terminal emulator is receiving when you press it.

Then if you still have an issue, please run /feedback and send the session id so we can investigate it.

jocado · 2 months ago

I did a bit of digging into this, and it seems like Shit+Enter has looked the same as Enter to Unix-like system terminal programs for quite some time. Largely for historic reasons, but it has perpetuated.

This seems to explain it fairly well: https://blog.fsck.com/agent-blog/2026/02/26/terminal-keyboard-protocol/

Modern keyboard protocols that are backward compatible have been developed, notably kitty, but it's not yet support in various Linux distros at least in the primary terminal applications, like anything based on Gnome VTE

That seems to suggest that this is not really "fixable" for Shit+Enter for many terminal applications, and probably it wasn't a good choice for a terminal application. I would suggest this workaround is potentially a good the way to go for now.