You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that the shift+enter keybinding, which is supposed to insert a newline in the input field, doesn’t seem to work. However, the alternative keybinding ctrl+j works fine for the same action.
Expected Behavior
When I press shift+enter, it should insert a newline in the input field.
Observed Behavior
Pressing shift+enter
Does nothing when the input is blank
Send the message when the input is not blank
On the other hand, ctrl+j works as expected and inserts a newline.
Steps to Reproduce
Open OpenCode.
Focus on an input field.
Press shift+enter to try inserting a newline.
Notice that nothing happens.
Environment
Platform: macOS M2 (version 14.6.1)
Terminal: tested on Terminal and Warp
Version: tested on dev branch
Analysis by Qwen3 Coder
That's the key! Looking at the editor code, I can see what's happening:
When a key event occurs, the editor first checks if msg.Text != "" (line 126)
If there's text in the message, it directly passes the message to the textarea's Update method (line 128)
ctrl+j is interpreted by the terminal as a newline character (\n), so msg.Text contains "\n"
This gets passed directly to the textarea, which inserts it as a newline
However, shift+enter is not interpreted as text by the terminal - it's sent as a special key event. Since there's no msg.Text for shift+enter, the code doesn't take the early return path, and instead continues to process the key event through the rest of the switch statement.
The issue is that shift+enter is not being handled specifically in the editor's key processing logic. Let me look at where commands are actually executed:
qwen/qwen3-coder:free (09:00 PM)
Now I understand the issue! Looking at the code flow:
In the TUI's Update method, key events are first checked against commands using a.app.Commands.Matches(msg, a.app.IsLeaderSequence) (line 304 in tui.go)
If a command matches, it gets executed via commands.ExecuteCommandsMsg(matches) (line 310)
The InputNewlineCommand is configured with keybindings for "shift+enter" and "ctrl+j" (line 299 in command.go)
The problem is that when shift+enter is pressed:
It matches the InputNewlineCommand
The command gets executed
But there's likely no handler for InputNewlineCommand that actually calls the editor's Newline() method
Let me check where commands are actually executed:
qwen/qwen3-coder:free (09:00 PM)
I face the same issue on mac built-in terminal and vscode.
Reacted by Andre van Tonder, Hadrian de Oliveira, Kyle Tse, Lee Sai Mun, Jeff Lunt, Chris Lemke, M. Corey Thompson, iahmadalyan, pythoninthegrass, Pasindu Ruwandeniya and 27 more
@wanjuntham some terminals/multiplexers don't pass this through right, you can use ctrl+j in those cases, or you can remap the keybind
yes ctrl + j works, but I am already so used to shift + enter keybind for inserting a new line.
Reacted by the-vampiire, Art Shendrik, Aaron McAdam, Fredy Sandoval, Tarek Haoula, donisewell, pythoninthegrass, Pasindu Ruwandeniya, James, Jeremy Akers and 7 more
Reacted by Aksel Blekastad, sirmo, Tobias Gårdhus, halo, Ivan Cordoba, Noel Garate, Syed Ibad Ullah, Jakub Baran, Joachim Hereth, Anomatomato and 1 more
I have noticed that when I am using tmux in ghostty terminal on my mac, the shift enter does not work in opencode.
Reacted by Moni, Ricardo Ander-Egg, Chau Tran, Nathan Papes, Niklas Wallerstedt, Aaron McAdam, Martin Mose Facondini, Husam Alshehadat, James G. Best, Thierry Delafontaine and 23 more
I still cannot get shift+enter works in Warp terminal (ctrl+j works), quite frustrating 😂
Ps. shift+enter works on iTerm2
Reacted by Art Shendrik, James Blair, gnoah1379, Kevin Schaich, Martin Alker, Alexandre Reyes Martins, pemontto, Chris Lemke, Dmitry Baginsky, JG and 11 more
Consider implementing a default configuration that works with vscode. ctrl + j is a default keybinding in vscode to toggle panel (e.g., terminal) visibility shift + enter doesn't work
Reacted by François Parmentier, Oscar Serna, Jeff Schumacher, Sleepstars, pythoninthegrass, gabrieltomasin, woonki, Michael Mortensen, Evgeny Evseev, Faisal Hakim and 3 more
@hamza-m-masood@hasanfaesal Thanks for sharing! I'm curious if there were some other steps left out or something... how did either of you get this working as-is?
...in ~/.config/opencode/tui.json (which didn't exist beforehand), and add the other two lines to tmux.conf (which came with one other line already, set -ga terminal-overrides ',xterm*:smcup@:rmcup@') and source the update as stated, it unfortunately doesn't work when I reattach, even if I create a new tmux window and open a fresh opencode.
I come to the conclusion that this is just a limitation of the terminal emulator if you don't have a way to remap the keys. OpenCode can't do anything if Terminal Emulator doesn't have such a feature.
@codingthat I ended up moving away from tmux and installed cmux terminal instead. Try it out! I think you will most probably like it and get used to it if you are proficient in tmux.
btw, if you are familiar with vim-motions, another option is to use plain old return, in insert mode, with this plugin i created: github.com/oribarilan/vimcode
I come to the conclusion that this is just a limitation of the terminal emulator if you don't have a way to remap the keys. OpenCode can't do anything if Terminal Emulator doesn't have such a feature.
Somehow other tools can do Shift+Enter just fine - only OpenCode is affected. This is just a limitation of OpenCode that needs fixing.
Reacted by Berat BAYRAM, Matt Davey, Gennaro Tedesco, Flavio Veloso Soares and Niek van de Pas
Looked into this a bit today and here is a summary for whoever shows up here to complain.
The reason why this is inconsistent is because it depends on how the terminal you are using encodes the keystroke when sending it to the pty, which is where opencode reads it from. There are three cases:
ghostty, Wezterm, Warp, alacritty and other newer terminals support the kitty protocol for keystroke encoding, and if opencode is doing the right thing, they should work. Some of these need kitty to be explicitly enabled; I know ghostty enables it by default.
Some terminals allow defining custom encodings for keystrokes; Windows Terminal I believe is an example
Now for the sad part. gnome-terminal (and the newer ptyxis) which gnome-based distros default to, and which both use the GNOME VTE library, do not yet support kitty nor allow configuring a custom encoding.
In the legacy (non-kitty) protocol, neither Ctrl- nor Shift-enter generate an encoding distinct from Enter. But Alt-Enter does, and it does work in gnome-terminal and ptyxis — but not in textareas like this one. Annoyingly, Ctrl-Enter submits so you can't learn to use that either!
If you want to know more than you need to about this issue, the kitty protocol link I provided above has the nitty gritty. There has been work done to implement kitty support in VTE but it's yet merged and may be stalled and looking for help.
Reacted by Daniel Loader, adong660, Ryan Hartlage and Niek van de Pas
No terminal remapping is needed for this raw CR/LF setup. Distinguishing Ctrl+Enter from Ctrl+J requires the terminal to send a distinct sequence, such as CSI-u.
Version note: this was tested with OpenCode v1.18.25, which uses OpenTUI v0.4.5. The same behavior remains in OpenTUI v0.5.9.
No terminal remapping is needed for this raw CR/LF setup. Distinguishing Ctrl+Enter from Ctrl+J requires the terminal to send a distinct sequence, such as CSI-u.
Version note: this was tested with OpenCode v1.18.25, which uses OpenTUI v0.4.5. The same behavior remains in OpenTUI v0.5.9.
Activity
the-vampiire commentedon Aug 15, 2025
I’m going to close #1941 but do want to note that this only happens in vscode for me. i dont have this issue when running in iterm or ghostty
fmatsos commentedon Aug 15, 2025
I have the issue on Fedora with ddterm. I know some teammates have the issue too, but idk which terminal (on linux distro too).
wanjuntham commentedon Aug 16, 2025
I face the same issue on mac built-in terminal and vscode.
rekram1-node commentedon Aug 16, 2025
@wanjuntham some terminals/multiplexers don't pass this through right, you can use ctrl+j in those cases, or you can remap the keybind
wanjuntham commentedon Aug 16, 2025
yes ctrl + j works, but I am already so used to shift + enter keybind for inserting a new line.
rekram1-node commentedon Aug 16, 2025
yes definitely annoying, kinda depends on your emulator tho, in ghostty and zed shift+enter works fine (many others too)
SMFloris commentedon Aug 16, 2025
In alacritty, you just need to add the following to map
shift+enterto\n.hamza-m-masood commentedon Aug 19, 2025
I have noticed that when I am using tmux in ghostty terminal on my mac, the shift enter does not work in opencode.
hd-o commentedon Aug 29, 2025
Same here in vscode. Solved by remapping submit, then
enterinputs a new line{ "keybinds": { "input_submit": "alt+enter", }, }CSRessel commentedon Sep 8, 2025
I actually have this issue in ghostty on Linux, but not when running another other TUI application I have built within ghostty
ahosker commentedon Sep 11, 2025
Very new to this tried Shift + Ender on
termiusand it acted as a submit.mrgoonie commentedon Sep 14, 2025
I still cannot get
shift+enterworks in Warp terminal (ctrl+jworks), quite frustrating 😂Ps.
shift+enterworks on iTerm2joseph-hlucny commentedon Sep 20, 2025
Consider implementing a default configuration that works with vscode.
ctrl + jis a default keybinding in vscode to toggle panel (e.g., terminal) visibilityshift + enterdoesn't workesafak commentedon Sep 23, 2025
shift+enter used to work in ghostty with macos, and it no longer does. I use nushell, if that helps.
111 remaining items
anentropic commentedon Mar 11, 2026
Why are the default keybindings so bad?
codingthat commentedon Mar 25, 2026
@hamza-m-masood @hasanfaesal Thanks for sharing! I'm curious if there were some other steps left out or something... how did either of you get this working as-is?
Aside from the missing quote marks, in
~/.config/opencode/opencode.jsonit's against the schema and I get an errorProperty keybinds is not allowed.According to https://opencode.ai/docs/keybinds/ it belongs in
tui.json, but even when I put this:{ "$schema": "https://opencode.ai/tui.json", "keybinds": { "input_newline": "shift+return", "input_submit": "return" } }...in
~/.config/opencode/tui.json(which didn't exist beforehand), and add the other two lines totmux.conf(which came with one other line already,set -ga terminal-overrides ',xterm*:smcup@:rmcup@') and source the update as stated, it unfortunately doesn't work when I reattach, even if I create a new tmux window and open a fresh opencode.jcubic commentedon Mar 25, 2026
I come to the conclusion that this is just a limitation of the terminal emulator if you don't have a way to remap the keys. OpenCode can't do anything if Terminal Emulator doesn't have such a feature.
hamza-m-masood commentedon Mar 25, 2026
@codingthat I ended up moving away from tmux and installed cmux terminal instead. Try it out! I think you will most probably like it and get used to it if you are proficient in tmux.
codingthat commentedon Mar 26, 2026
Many thanks @hamza-m-masood — I'm on Linux Mint but I appreciate the recommendation nonetheless =)
Grey2k commentedon Apr 2, 2026
hi, any ideas about MacOS with JetBrains IDE Terminal -
shift+enter works well in iTerm2 , but not in IDE
feat(app): enforce desktop restriction policies (anomalyco#1505)
Task/react port cutover react only workspace fixes (anomalyco#1470)
anggaaryas commentedon May 17, 2026
Both shift + return and opt + return doesnt work in mac default terminal.
zjtalia commentedon May 27, 2026
for tmux users, the workaround detailed in this claude code issue worked for me!
Also, the
Proposed Fixfrom the linked issue would be a simple way for OpenCode to resolve this issue as well.oribarilan commentedon May 27, 2026
btw, if you are familiar with vim-motions, another option is to use plain old return, in insert mode, with this plugin i created:
github.com/oribarilan/vimcode
Nowaker commentedon Jun 3, 2026
Somehow other tools can do Shift+Enter just fine - only OpenCode is affected. This is just a limitation of OpenCode that needs fixing.
kikoreis commentedon Jun 4, 2026
Looked into this a bit today and here is a summary for whoever shows up here to complain.
The reason why this is inconsistent is because it depends on how the terminal you are using encodes the keystroke when sending it to the pty, which is where opencode reads it from. There are three cases:
In the legacy (non-kitty) protocol, neither Ctrl- nor Shift-enter generate an encoding distinct from Enter. But Alt-Enter does, and it does work in gnome-terminal and ptyxis — but not in textareas like this one. Annoyingly, Ctrl-Enter submits so you can't learn to use that either!
If you want to know more than you need to about this issue, the kitty protocol link I provided above has the nitty gritty. There has been work done to implement kitty support in VTE but it's yet merged and may be stalled and looking for help.
AlwaysYng commentedon Aug 31, 2026
OpenCode TUI: Use
linefeedInstead ofctrl+jforinput_submitIn my tests with Windows Terminal and XShell 8 using
showkey -a:\r(0x0d)return\r(0x0d)return\r(0x0d)return\n(0x0a)linefeed\n(0x0a)linefeedOpenTUI parses raw
\naslinefeed, which Textarea maps to a newline.To make Enter insert a newline and Ctrl+Enter submit, use:
{ "$schema": "https://opencode.ai/tui.json", "keybinds": { "input_newline": "return", "input_submit": "linefeed" } }Result:
No terminal remapping is needed for this raw CR/LF setup. Distinguishing Ctrl+Enter from Ctrl+J requires the terminal to send a distinct sequence, such as CSI-u.
Version note: this was tested with OpenCode
v1.18.25, which uses OpenTUIv0.4.5. The same behavior remains in OpenTUIv0.5.9.Relevant OpenTUI v0.5.9 source:
\r/\nparsinglinefeed -> newlinedefault bindingrahul-behera commentedon Oct 21, 2026
Thanks this worked for. Other suggestions didn't.