anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Keyboard shortcuts to edit prompts suck so much! #3226

New Issue
Closed
opened 2026-02-16 17:39:13 -05:00 by yindo · 15 comments
yindo commented 2026-02-16 17:39:13 -05:00
Owner
Copy Link
Copy Source

Originally created by @lcswillems on GitHub (Dec 1, 2025).

Originally assigned to: @kommander on GitHub.

Description

I'm in love with opencode! However, the editing experience for writting prompts (which is an essential piece of such a CLI) is very bad because a bunch of keyboard shortcuts don't work.

  • I can't enter a new line. shift+enter submits, ctrl+enter submits. ctrl+j is a default shortcut in VSCode. For every other CLI (e.g. codex), ctrl+enter inserts a new line.
    Related issues: https://github.com/sst/opencode/issues/1505, https://github.com/sst/opencode/issues/4189
  • I can't navigate fast across a prompt (e.g. I want to edit a part of the prompt way ealier or way latter than where I am right now) and need to keep pressing "left" / "right" for a while:
  • I can't delete the word just after with ctrl+suppr. It deletes everything (before and after!!). The standard is ctrl+delete to delete the word before (it works) and ctrl+suppr to delete the word after. It doesn't work.

There are already a lot of issues on this subject, but they don't seem to be worked on at all, while it seems to be a very important matter. The single biggest reason I'm looking for alternatives to opencode is because the editing experience is so bad right now.

Context: I'm on Ubuntu and I use opencode in a terminal opened in VSCode.

OpenCode version

v1.0.123

Originally created by @lcswillems on GitHub (Dec 1, 2025). Originally assigned to: @kommander on GitHub. ### Description I'm in love with opencode! However, the editing experience for writting prompts (which is an essential piece of such a CLI) is very bad because a bunch of keyboard shortcuts don't work. - I can't enter a new line. `shift+enter` submits, `ctrl+enter` submits. `ctrl+j` is a default shortcut in VSCode. For every other CLI (e.g. codex), `ctrl+enter` inserts a new line. Related issues: https://github.com/sst/opencode/issues/1505, https://github.com/sst/opencode/issues/4189 - I can't navigate fast across a prompt (e.g. I want to edit a part of the prompt way ealier or way latter than where I am right now) and need to keep pressing "left" / "right" for a while: - I can't jump to the previous / next word. `ctrl+left` and `ctrl+right` don't work while the standard is to jump before / after word. Related issues: https://github.com/sst/opencode/issues/1975, https://github.com/sst/opencode/issues/3090, - I can't jump to the beginning / end of the prompt. `ctrl+pageup` and `ctrl+pagedown` scroll the conversation, instead of the standard jump to beginning / end of text. Related issues: https://github.com/sst/opencode/issues/2649 - I can't delete the word just after with `ctrl+suppr`. It deletes **everything** (before and after!!). The standard is `ctrl+delete` to delete the word before (it works) and `ctrl+suppr` to delete the word after. It doesn't work. There are already a lot of issues on this subject, but they don't seem to be worked on at all, while it seems to be a very important matter. The single biggest reason I'm looking for alternatives to opencode is because the editing experience is so bad right now. **Context: I'm on Ubuntu and I use opencode in a terminal opened in VSCode.** ### OpenCode version [v1.0.123](https://github.com/sst/opencode/releases/tag/v1.0.123)
yindo added the opentuibug labels 2026-02-16 17:39:13 -05:00
yindo closed this issue 2026-02-16 17:39:13 -05:00
yindo commented 2026-02-16 17:39:14 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 1, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #1975: ctrl + arrow key no longer moves word-to-word
  • #3090: add ctrl+left/right to navigate by word
  • #2649: Standard keyboard cursor navigation (Home/End key, ctrl+left/right key)
  • #3370: Text selection and navigation inside input with keyboard
  • #3978: Cannot Navigate the TextArea using Ctrl and Alt
  • #4261: Option+Right not jumping words as intended in some scenarios

These existing issues cover the keyboard navigation shortcut problems you're experiencing. Feel free to ignore if your case has additional specific requirements not addressed in these issues.

@github-actions[bot] commented on GitHub (Dec 1, 2025): This issue might be a duplicate of existing issues. Please check: - #1975: ctrl + arrow key no longer moves word-to-word - #3090: add ctrl+left/right to navigate by word - #2649: Standard keyboard cursor navigation (Home/End key, ctrl+left/right key) - #3370: Text selection and navigation inside input with keyboard - #3978: Cannot Navigate the TextArea using Ctrl and Alt - #4261: Option+Right not jumping words as intended in some scenarios These existing issues cover the keyboard navigation shortcut problems you're experiencing. Feel free to ignore if your case has additional specific requirements not addressed in these issues.
yindo commented 2026-02-16 17:39:14 -05:00
Author
Owner
Copy Link
Copy Source

@ariane-emory commented on GitHub (Dec 1, 2025):

By default opencode uses the de-facto standard emacs/readline/MacOS style keybindings used by most other applications, such as alt+left/alt+right to move wordwise, alt+backspace to delete the word preceding point and ctrl+a/ctrl+e to move point to the start/end of input fields.

Preferred key bindings are ultimately a matter of individual user preference, and so far as I'm aware all of the keys you've mentioned can be re-bound in your opencode.jsonc file's "keybinds" property. If you prefer the strange keybindings that Windows prefers, there's nothing stopping you from configuring them right now. Not a bug, IMO.

@ariane-emory commented on GitHub (Dec 1, 2025): By default opencode uses the de-facto standard emacs/readline/MacOS style keybindings used by most other applications, such as `alt+left`/`alt+right` to move wordwise, `alt+backspace` to delete the word preceding point and `ctrl+a`/`ctrl+e` to move point to the start/end of input fields. Preferred key bindings are ultimately a matter of individual user preference, and so far as I'm aware all of the keys you've mentioned can be re-bound in your `opencode.jsonc` file's `"keybinds"` property. If you prefer the strange keybindings that Windows prefers, there's nothing stopping you from configuring them right now. Not a bug, IMO.
yindo commented 2026-02-16 17:39:14 -05:00
Author
Owner
Copy Link
Copy Source

@lcswillems commented on GitHub (Dec 1, 2025):

@ariane-emory How could those keybinds be customized? They don't appear in the settings in opencode.jsonc or I missed them?

The market share of editors proposing ctrl+left, ctrl+right, etc (e.g. VSCode) is maybe an order of magnitude higher than the one of editors that propose alt+left, alt+right, alt+backspace, ctrl+a, ctrl+e, etc (e.g. emacs).

Furthermore, the common places for writting (e.g. Firefox, Chrome, Slack, etc) support the former keybinds rather than the later ones.

So very likely that people are in general way more likely to be used to the former ones than the later ones.

@lcswillems commented on GitHub (Dec 1, 2025): @ariane-emory How could those keybinds be customized? They don't appear in the settings in opencode.jsonc or I missed them? The market share of editors proposing `ctrl+left`, `ctrl+right`, etc (e.g. VSCode) is maybe an order of magnitude higher than the one of editors that propose `alt+left`, `alt+right`, `alt+backspace`, `ctrl+a`, `ctrl+e`, etc (e.g. emacs). Furthermore, the common places for writting (e.g. Firefox, Chrome, Slack, etc) support the former keybinds rather than the later ones. So very likely that people are in general way more likely to be used to the former ones than the later ones.
yindo commented 2026-02-16 17:39:14 -05:00
Author
Owner
Copy Link
Copy Source

@ariane-emory commented on GitHub (Dec 1, 2025):

Personally, I prefer my keyboard bindings to to be even more similar to emacs than opencode's defaults. So, I've got this in my opencode.json:

  "keybinds": {
    "model_cycle_recent_reverse": "alt+k",
    "model_cycle_recent": "alt+j",
    "command_list": "alt+x",
    "history_next": "ctrl+n",
    "history_previous": "ctrl+p",
    "session_child_cycle": "ctrl+right",
    "session_child_cycle_reverse": "ctrl+left",
  },

If you'd like to figure out the names for particular commands, I've found that the best way to get those answers is to launch opencode in it's own source code's directory and ask it - any decent model will do, the free opencode/big-pickle is usually pretty great at answering this type of question.

@ariane-emory commented on GitHub (Dec 1, 2025): Personally, I prefer my keyboard bindings to to be _even more_ similar to emacs than opencode's defaults. So, I've got this in my `opencode.json`: ```json "keybinds": { "model_cycle_recent_reverse": "alt+k", "model_cycle_recent": "alt+j", "command_list": "alt+x", "history_next": "ctrl+n", "history_previous": "ctrl+p", "session_child_cycle": "ctrl+right", "session_child_cycle_reverse": "ctrl+left", }, ``` If you'd like to figure out the names for particular commands, I've found that the best way to get those answers is to launch opencode in it's own source code's directory and ask it - any decent model will do, the free `opencode/big-pickle` is usually pretty great at answering this type of question.
yindo commented 2026-02-16 17:39:14 -05:00
Author
Owner
Copy Link
Copy Source

@lcswillems commented on GitHub (Dec 2, 2025):

Thanks @ariane-emory for the help!! 🙏 🙏

@lcswillems commented on GitHub (Dec 2, 2025): Thanks @ariane-emory for the help!! 🙏 🙏
yindo commented 2026-02-16 17:39:14 -05:00
Author
Owner
Copy Link
Copy Source

@Nindaleth commented on GitHub (Dec 11, 2025):

as of 1.0.147 this is much improved

the only remaining issue is that newline can only be entered by ctrl+j (while its other keybinds don't work); the rest seems to work for me now

@Nindaleth commented on GitHub (Dec 11, 2025): as of 1.0.147 this is much improved the only remaining issue is that newline can only be entered by ctrl+j (while its other keybinds don't work); the rest seems to work for me now
yindo commented 2026-02-16 17:39:14 -05:00
Author
Owner
Copy Link
Copy Source

@MilesNorton commented on GitHub (Dec 11, 2025):

@Nindaleth What OS and terminal are you using? I can use shift+enter to go to a new line and I can set the keybind ("input_newline") on linux

@MilesNorton commented on GitHub (Dec 11, 2025): @Nindaleth What OS and terminal are you using? I can use shift+enter to go to a new line and I can set the keybind ("input_newline") on linux
yindo commented 2026-02-16 17:39:14 -05:00
Author
Owner
Copy Link
Copy Source

@Nindaleth commented on GitHub (Dec 11, 2025):

@MilesNorton this is on Linux and Terminator terminal. I checked on Ghostty and shift+enter works there now, so it's just some terminals even on Linux.

@Nindaleth commented on GitHub (Dec 11, 2025): @MilesNorton this is on Linux and Terminator terminal. I checked on Ghostty and shift+enter works there now, so it's just some terminals even on Linux.
yindo commented 2026-02-16 17:39:14 -05:00
Author
Owner
Copy Link
Copy Source

@Nindaleth commented on GitHub (Dec 11, 2025):

From the default shortcuts of "shift+return,ctrl+return,alt+return,ctrl+j", I found the alt+enter also works in addition to ctrl+j to produce a newline in Terminator, I might use alt+enter in the meantime

I understand that the path forward is a more modern terminal, but I'm delaying the switch to Ghostty as it's not yet a clear improvement over Terminator.

@Nindaleth commented on GitHub (Dec 11, 2025): From the default shortcuts of `"shift+return,ctrl+return,alt+return,ctrl+j"`, I found the alt+enter also works in addition to ctrl+j to produce a newline in Terminator, I might use alt+enter in the meantime I understand that the path forward is a more modern terminal, but I'm delaying the switch to Ghostty as it's not yet a clear improvement over Terminator.
yindo commented 2026-02-16 17:39:14 -05:00
Author
Owner
Copy Link
Copy Source

@kommander commented on GitHub (Dec 15, 2025):

shift+enter will only work in terminals that support modifyOtherKeys or kitty keyboard protocol, there is nothing opencode or opentui can do about that. Default navigation keybinds have been extended and all textarea text nav input_* bindings can now be customized, see https://opencode.ai/docs/keybinds/

@kommander commented on GitHub (Dec 15, 2025): `shift+enter` will only work in terminals that support modifyOtherKeys or kitty keyboard protocol, there is nothing opencode or opentui can do about that. Default navigation keybinds have been extended and all textarea text nav `input_*` bindings can now be customized, see [https://opencode.ai/docs/keybinds/](https://opencode.ai/docs/keybinds/)
yindo commented 2026-02-16 17:39:14 -05:00
Author
Owner
Copy Link
Copy Source

@lcswillems commented on GitHub (Dec 15, 2025):

@kommander For example, when I do "shift+enter" in Codex inside VSCode, I don't have this issue. Why?

@lcswillems commented on GitHub (Dec 15, 2025): @kommander For example, when I do "shift+enter" in Codex inside VSCode, I don't have this issue. Why?
yindo commented 2026-02-16 17:39:14 -05:00
Author
Owner
Copy Link
Copy Source

@kommander commented on GitHub (Dec 15, 2025):

Codex manipulates your vscode config and adds a custom keybinding sending a custom sequence that only Codex handles. Opencode will get some setup scripts to tweak terminal configs where possible, but as opt-in, to avoid surprises when conflicts happen, as has happened before with claude code manipulating the Ghostty config.

@kommander commented on GitHub (Dec 15, 2025): Codex manipulates your vscode config and adds a custom keybinding sending a custom sequence that only Codex handles. Opencode will get some setup scripts to tweak terminal configs where possible, but as opt-in, to avoid surprises when conflicts happen, as has happened before with claude code manipulating the Ghostty config.
yindo commented 2026-02-16 17:39:14 -05:00
Author
Owner
Copy Link
Copy Source

@jdanbrown commented on GitHub (Dec 15, 2025):

Codex manipulates your vscode config and adds a custom keybinding sending a custom sequence that only Codex handles. Opencode will get some setup scripts to tweak terminal configs where possible, but as opt-in, to avoid surprises when conflicts happen, as has happened before with claude code manipulating the Ghostty config.

Thank you for planning to make it opt-in! It's very frustrating when app A goes and quietly mucks with the config of app B without making it clear to the user what was changed, and how they can control it themselves.

@jdanbrown commented on GitHub (Dec 15, 2025): > Codex manipulates your vscode config and adds a custom keybinding sending a custom sequence that only Codex handles. Opencode will get some setup scripts to tweak terminal configs where possible, but as opt-in, to avoid surprises when conflicts happen, as has happened before with claude code manipulating the Ghostty config. Thank you for planning to make it opt-in! It's very frustrating when app A goes and quietly mucks with the config of app B without making it clear to the user what was changed, and how they can control it themselves.
yindo commented 2026-02-16 17:39:14 -05:00
Author
Owner
Copy Link
Copy Source

@lcswillems commented on GitHub (Dec 16, 2025):

I've added this to my VSCode config and now it works!!

{
    "key": "shift+enter",
    "command": "workbench.action.terminal.sendSequence",
    "args": {
      "text": "\u001B\u000A"
    },
    "when": "terminalFocus"
  },
@lcswillems commented on GitHub (Dec 16, 2025): I've added this to my VSCode config and now it works!! ``` { "key": "shift+enter", "command": "workbench.action.terminal.sendSequence", "args": { "text": "\u001B\u000A" }, "when": "terminalFocus" }, ```
yindo commented 2026-02-16 17:39:14 -05:00
Author
Owner
Copy Link
Copy Source

@gitTerebi commented on GitHub (Feb 1, 2026):

Part of problem is that you are trying to edit in a CLI, it doesn't really like it if you try to copy output from it that spans multiple screens either

@gitTerebi commented on GitHub (Feb 1, 2026): Part of problem is that you are trying to edit in a CLI, it doesn't really like it if you try to copy output from it that spans multiple screens either
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label bug opentui
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3226
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?