Regression: Alt+Enter no longer inserts newline in VS Code WSL terminal

@rafael-agenticca this is a true regression. Can you add this to your ~/.codex/config.toml until 0.129.0 is released:

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

And let me know if it works for you.

Thank you for reporting!

@fcoury-oai thanks for confirming.

Unfortunately I won’t be able to test this reliably anymore because I already worked around the issue in my local environment. I removed/remapped the VS Code shortcuts that were intercepting Alt+Enter, so the original failure no longer reproduces for me here.

That said, it would be useful if someone else who is still experiencing the issue could test the proposed config workaround:

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

This would help confirm whether the issue can be resolved only by adding alt-enter to ~/.codex/config.toml, without changing VS Code keybindings.

Thanks again for looking into it.

+1, macOS, Apple Terminal, codex-cli 0.128.0. Had to manually re-add key bindings for "alt-enter".

@rafael-agenticca this is a true regression. Can you add this to your ~/.codex/config.toml until 0.129.0 is released: [tui.keymap.editor] insert_newline = ["ctrl-j", "ctrl-m", "enter", "shift-enter", "alt-enter"] And let me know if it works for you. Thank you for reporting!

I confrim this fix is working

I also bumped into this issue while using Codex CLI 0.128.0 on macOS. I was able to temporarily fix it with the keymap settings @fcoury-oai shared ↓ . Thanks!

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

I also bumped into this issue while using Codex CLI 0.128.0 on macOS. I was able to temporarily fix it with the keymap settings @fcoury-oai shared ↓ . Thanks!

Thanks for confirming it works for you, this way we can reference this issue until we have the fix out.

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

I can confirm that this fix does 'not' work for the newline insertion issue I've been having in the Zed integrated terminal. As I said in #20555:

This issue is about Shift+Enter in Zed being reported as LF / U+000A, which corresponds to Ctrl+J in C0 control-code terms. Ctrl+J is already included in the default editor.insert_newline bindings, but U+000A is not normalized to Ctrl+J in key_hint.rs, so the existing binding does not match.

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

insert_newline fixed it on Konsole.

I can reproduce a similar regression on Windows with the Zed integrated terminal.

For me:

• Codex 0.125.x: Shift+Enter inserted a new line in Zed
• Codex 0.128.x: Shift+Enter no longer inserts a new line in Zed
• In my environment, Ctrl+J also does not insert a new line in Zed, even when configured to be passed through.
• Windows Terminal on the same machine still works with Codex 0.128.x.

So this does not seem to be limited to macOS. In my case, it looks like a terminal-specific key handling regression or compatibility issue exposed by the newer TUI keyboard handling.

So this does not seem to be limited to macOS. In my case, it looks like a terminal-specific key handling regression or compatibility issue exposed by the newer TUI keyboard handling.

Yes. Both Shift+Enter and Ctrl+J produce the C0 control character U+000A in the Zed integrated terminal. I tested both.

The input normalization helper in key_hint.rs is missing a case to normalize U+000A to Some('j'):

fn c0_control_char_to_ctrl_char(ch: char) -> Option<char> {
    match ch {
        '\u{0002}' => Some('b'),
        '\u{0006}' => Some('f'),
        '\u{000e}' => Some('n'),
        '\u{0010}' => Some('p'),
        '\u{0012}' => Some('r'),
        '\u{0013}' => Some('s'),
        _ => None,
    }
}

Adding the one line would be enough to fix this, I think:

'\u{000a}' => Some('j'),

I have a small patch ready for the Zed/Ctrl+J path discussed above, but GitHub is currently showing that PR creation is limited to repository collaborators:

https://github.com/openai/codex/compare/main...misrtjakub:fix/codex-shift-enter-newline?expand=1

It adds the \u{000a} -> j normalization in key_hint.rs with a focused unit test. If issue-linked compare branches are an acceptable external contribution path, this should cover the C0 LF case from #20555.

I have a small patch ready for the Zed/Ctrl+J path discussed above, but GitHub is currently showing that PR creation is limited to repository collaborators: https://github.com/openai/codex/compare/main...misrtjakub:fix/codex-shift-enter-newline?expand=1 It adds the \u{000a} -> j normalization in key_hint.rs with a focused unit test. If issue-linked compare branches are an acceptable external contribution path, this should cover the C0 LF case from #20555.

I proposed the same fix. I guess we'll see how things work out when 0.129.0 gets released.

Edit: Looks like there will be a proper fix!

I appreciate the proposal, we have addressed all the C0 normalizations as part of this PR that is still being reviewed:

https://github.com/openai/codex/pull/20798

I appreciate the proposal, we have addressed all the C0 normalizations as part of this PR that is still being reviewed: #20798

That's great news. Thanks.