tui: Shift+Enter submits instead of inserting newline in macOS Terminal.app (worked in V1) #43286

Summary

Since V2, pressing Shift+Enter in the macOS built-in Terminal (Terminal.app) submits the prompt instead of inserting a newline — even with alt+return explicitly bound to input.newline. This worked in V1 with the same terminal and the same keypress. The V2 input stack (opentui) no longer resolves Terminal.app's ambiguous ESC+CR sequence.

Environment

• opencode version: 0.0.0-beta-17519 (beta)
• OS: Darwin 27.0.0 (macOS, arm64)
• Terminal: Terminal.app (TERM_PROGRAM=Apple_Terminal, TERM=xterm-256color)
• Shell: /bin/zsh
• Install/channel: beta
• Active plugins: opencode-claude-auth-v2, a custom TUI sidebar plugin (neither affects input handling)

Reproduction

1. In macOS Terminal.app, run opencode2.
2. Type some text in the prompt.
3. Press Shift+Enter.
4. The prompt submits instead of inserting a newline.

Raw bytes captured from Terminal.app: pressing Shift+Enter sends ESC + CR (\x1b\r) in raw mode (ESC + LF in cooked mode, i.e. cat -v shows ^[ then a line break). Terminal.app does not support the kitty keyboard protocol, so this is the only encoding it can produce.

Expected Behavior

Shift+Enter inserts a newline. This worked in V1 in the same Terminal.app with the same keypress.

Actual Behavior

Shift+Enter submits the prompt. Only ctrl+j inserts a newline.

Additional Context

Keybind combinations tried in ~/.config/opencode/cli.json (each tested after a full TUI restart):

{ "keybinds": { "input.newline": "shift+return,ctrl+return,alt+return,ctrl+j" } }
{ "keybinds": { "input.newline": "shift+return,ctrl+return,alt+return,alt+linefeed,ctrl+j" } }

Neither restores Shift+Enter in Terminal.app. opentui's keypress parser (packages/core/src/lib/parse.keypress.ts) decodes \x1b\r as { name: "return", meta: true } and \x1b\n as { name: "linefeed", meta: true }, so alt+return/alt+linefeed should match — but the event does not reach the keybind matcher as such (or is consumed by the submit path).

Notes:

• V1's default input_newline included alt+return and worked in Terminal.app; the V2 default keybind is shift+return,ctrl+return,ctrl+j — alt+return was dropped, and re-adding it does not help.
• Terminals with kitty keyboard protocol support (Ghostty, Kitty, WezTerm, iTerm2) send an unambiguous Shift+Enter and the default shift+return binding works there — confirming the byte stream is the only difference.
• Related earlier reports: Shift-return does not input newline since 1.0 #4046, Starting from opencode 1.1.22, shift+enter and ctrl+enter are not working. #8926, Shift+Enter submits prompt instead of inserting newline #30544, pinned Keybinds #4997. PR fix(prompt-input): handle Shift+Enter before IME check to prevent stuck state #8275 previously fixed similar newline handling in V1.
• Impact: every macOS Terminal.app (and similar non-kitty-protocol terminal) user on V2 loses multiline prompt entry.

Workaround

ctrl+j inserts a newline; Shift+Enter works in kitty-protocol terminals (e.g. Ghostty). Neither is the stock-terminal experience V1 provided.