[NaderIkladious]

Issue for this PR

Closes #17457

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Terminals using the Kitty keyboard protocol report numpad Enter as kpenter (codepoint 57414), which is distinct from return (main Enter). The TUI only checked for evt.name === "return", so pressing numpad Enter did nothing — no message submission, no dialog confirmation, no option selection.

This PR adds an isReturn helper that matches both "return" and "kpenter", and uses it across all keyboard handlers and textarea keybindings in the TUI.

Changes:

• Added isReturn() helper in src/util/keybind.ts
• Replaced all evt.name === "return" checks in TUI keyboard handlers with isReturn(evt.name)
• Added { name: "kpenter", action: "submit" } to textarea keybindings (main prompt, dialog-prompt, dialog-export-options)
• Added kpenter case to Keybind.parse() for config support

How did you verify your code works?

• Ran bun typecheck from packages/opencode — passes cleanly
• Full turbo typecheck across all 13 packages passes with zero errors
• Verified no remaining evt.name === "return" checks exist in the CLI/TUI code via grep

Screenshots / recordings

N/A — keyboard input behavior change, no visual UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[bwendell]

Thanks for working on this. I’m seeing the same thing on macOS with Ghostty 1.3.1 and OpenCode 1.3.13, where keypad Enter won’t submit in the TUI but regular Enter does. If helpful, I’m happy to test a follow-up build or confirm whether this PR fixes it for me.

[Mehdi-afs]

when is this going to be merged?

[thdxr]

This branch has been upgraded to V2. We're no longer taking PRs for V1. If you think this is still relevant, please port it over and open it for V2.

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊