Shift + Enter newline ignored in Zed integrated terminal

[therealmarrakesh]

What version of Codex CLI is running?

codex-cli 0.128.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.5

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What terminal emulator and version are you using (if applicable)?

Zed integrated terminal, Zed 1.0.0, PowerShell 5.1

What issue are you seeing?

After upgrading to Codex CLI 0.128.0, pressing Shift+Enter no longer inserts a newline in the Codex TUI when running inside the Zed integrated terminal. Instead, pressing Shift+Enter does nothing at all.

Pressing Shift+Enter properly inserted newlines in 0.125.0. Downgrading to 0.125.0 restores the expected behavior.

What steps can reproduce the bug?

1. On Windows, open Zed editor.
2. Open the Zed integrated terminal.
3. Run codex.
4. Type some text.
5. Press Shift+Enter.

What is the expected behavior?

Shift+Enter should insert a newline.

Additional information

In the Zed integrated terminal, Shift+Enter is reported as LF / U+000A, which corresponds to Ctrl+J in C0 control-code terms:

PowerShell `[Console]::ReadKey($true)` output:
Shift+Enter:
KeyCharCode : U+000A / decimal 10
Key                 : Enter
Modifiers       : Control

In previous version 0.125.0, this was directly handled in textarea.rs here:

KeyEvent {
                code: KeyCode::Char('j' | 'm'),
                modifiers: KeyModifiers::CONTROL,
                ..
            }
            | KeyEvent {
                code: KeyCode::Enter,
                ..
            } => self.insert_str("\n"),

But now newline handling goes through this keymap path in 0.128.0:

if keymap.insert_newline.is_pressed(event) {
    self.insert_str("\n");
    return;
}

Ctrl+J is bound to insert_newline:

editor: EditorKeymap {
                insert_newline: default_bindings![
                    ctrl(KeyCode::Char('j')),
                    ctrl(KeyCode::Char('m')),
                    plain(KeyCode::Enter),
                    shift(KeyCode::Enter)
                ],

But U+000A is not normalized to Ctrl+J in key_hint.rs:

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,
    }
}

Suggested Fix:

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

This new match arm should normalize U+000A to logical Ctrl+J, which should then match the existing insert_newline binding in EditorKeymap in keymap.rs.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

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

Powered by Codex Action

[therealmarrakesh]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

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

Powered by Codex Action

Thank you. But I believe this issue is not the same, even if it is adjacent.

#20501 is about Alt+Enter not being included as a newline alias.

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.

[misrtjakub]

I can take a small pass at this. The current C0 control-char normalization in codex-rs/tui/src/key_hint.rs does not map LF (\u{000a}) to Ctrl+J, while insert_newline already binds Ctrl+J. I’ll add that mapping with a focused unit test unless maintainers prefer a different normalization layer.

[misrtjakub]

Follow-up: I have a small patch ready, 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

Could a maintainer confirm the preferred way for external contributors to submit this?

[WodenJay]

Me too. I think it's a bug cuzz I can see ctrl-j, ctrl-m, enter, shift-enter when I use /keymap and select Insert Newline in codex-cli.