sst
Keybinds
Keybind issues in TUI: broken navigation (ctrl+n/p, ctrl+left/right), word deletion (option+delete, alt+d), multiline input (shift+enter, ctrl+enter), inconsistent emacs bindings (ctrl+a, ctrl+k), custom keybind remapping not working, Windows ctrl+c quits app instead of copy.
Related Issues:
- #4938 - Keyboard shortcuts to edit prompts suck so much!
- #4877 - Emacs keybindings frustratingly inconsistent
- #4965 - option delete doesn't delete word by word
- #4902 - ctrl+n/p not work in the picker anymore
- #4808 - Alt+d can no longer be remapped
- #2999 - Provide means to disable Ctrl-C (Windows quits app)
- #4531 - [FEATURE]: Expose way to set a specific agent of a running instance (sdk/api/keybind)
- #4432 - [FEATURE]: "session_child_return_to_parent" in keybinds
Not sure if related, but 1.0.128 is unusable for me because of keyboard woes: Tab as well as Backspace are triggered twice for each press. Effectively I can't switch between Build/Plan mode. Navigation/deletion related keybindings (Alt-b/f, Ctrl-a/e, Ctrl-k, etc) do work for me though.
Not sure if related, but 1.0.128 is unusable for me because of keyboard woes: Tab as well as Backspace are triggered twice for each press. Effectively I can't switch between Build/Plan mode. Navigation/deletion related keybindings (Alt-b/f, Ctrl-a/e, Ctrl-k, etc) do work for me though.
I am also having the double triggering happen and it is driving me crazy! I can't choose sessions anymore (it auto selects the top session), and I cannot tab between build and plan without holding the tab key like spinning the wheel and hoping it lands on the mode I want.
I am on 1.0.127 right now but I think it started happening to me on Saturday or Sunday.
I use alacritty 0.14.0 in zsh on MacOS.
I did a bisect on the versions, and the issue @csinko and myself are seeing start with 1.0.120.
First time using Opencode and I'm having the craziest issues with keybinds on mac.
There seems to be no mac modifier keys, cmd or option for example.
Trying to use alt (assuming that alt maps to option?) as a modifier in the keybinds config doesn't seem to work. Things like alt+p just don't register.
Also having issues with input_newline and input_submit, I just want to be able to type newlines with return and submit prompts using cmd+return or shift+return or anything else really.
For example:
"keybinds": {
"input_newline": "return",
"input_submit": "shift+return",
},
Remapping input_sumbit to shift+return still submits the prompt with just return. 😑
I'm on a fresh Sequoia 15.5 (24F74) install, using Warp terminal.
Is this typical?
I used to have model_list bound to ctrl+m. This has always worked fine prior to today, but this seems to no longer work on the latest version of opencode, making this a significant regression in the current version relative to earlier versions.
Binding it to alt+m, on the other hand, does work, leading me to suspect that something has been recently broken about binding commands to ctrl+m specifically.
I asked one of the robots, and it laid the blame here:
Timeline of Changes:
1. Before Dec 10: useKittyKeyboard: true - The Kitty keyboard protocol was enabled, which allows terminals that support it to properly distinguish Ctrl+M from Enter.
2. Commit ba1c6122b (Dec 10, 15:01 UTC+1): Changed useKittyKeyboard: true → useKittyKeyboard: {} to fix "doubled key events on some older terminal emulators"
3. Commit cc0567553 (Dec 10, 15:12 UTC-5): Changed useKittyKeyboard: {} → useKittyKeyboard: false to fix a type error
I'm using iTerm2 on the latest Sequoia.
Yeah, bot was right, I made a personal branch that re-enables Kitty and it does solve the issue.
@ariane-emory Commit cc0567553 does not exist. On dev it is this:
which means kitty keyboard is enabled. I don't know where that Timeline of Changes comes from. How did you "re-enable kitty"?
@kommander Hah, my bot must have hallucinated a commit.
For the 'fix', the useKittyKeyboard line was changed to:
useKittyKeyboard: { events: true } as any,
Didn't analyze this too closely as it's just a (hopefully temporary) personal hack branch, but it does seem to have made my ctrl+m binding work again, which was good enough for me in the context of a quick personal hack that I don't plan on trying to PR (I'll leave it to the folks who're more familiar with the Kitty protocol than I to come up with a more proper long term solution).
The kitty events mode was causing issues on older emulators and without it MacOS at least sends \r for ctrl+m. I'll make this flag configurable and turn it on by default again, so users that have issues can turn it off.
v0.1.147 now allows to configure custom bindings for all Textarea input actions. See https://opencode.ai/docs/keybinds/ for additional input_* binding possibilities.
Great job @kommander !!
For some keybinds, it seems that the config doesn't work and they get overridden by OpenCode itself. For example, I want "shift+enter" to be used for new line, or I want "Home" to go to the beginning of the line (but it gets overridden).
shift+enter does not work in all terminals and only with config tweaking in tmux, what terminal are you using?
Yeah shift+enter only works there if you remap it to send \n in you config
@kommander For some reason, shift+enter is in fact adding newlines for me despite not having configured it to do so in opencode.json. I'm not complaining though, I like it this way.
You mean in VSCode? The opencode config by default maps shift+enter for newline, as that is what most people expect. If it works for you, your are not using vscode or something changed your vscode config and mapped it for you. Gemini CLI does that for example.
@kommander No, sorry, iTerm2. I thought you were speaking generally, perhaps I misunderstood.