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

Keybinds #3262

New Issue
Open
opened 2026-02-16 17:39:23 -05:00 by yindo · 28 comments
yindo commented 2026-02-16 17:39:23 -05:00
Owner
Copy Link
Copy Source

Originally created by @rekram1-node on GitHub (Dec 2, 2025).

Originally assigned to: @kommander on GitHub.

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.

Please also consider the docs: https://opencode.ai/docs/keybinds/

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
Originally created by @rekram1-node on GitHub (Dec 2, 2025). Originally assigned to: @kommander on GitHub. 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. **Please also consider the docs:** https://opencode.ai/docs/keybinds/ **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
yindo added the discussion label 2026-02-16 17:39:23 -05:00
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

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

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.

@mgrachten commented on GitHub (Dec 2, 2025): 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.
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

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

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.

@csinko commented on GitHub (Dec 2, 2025): > 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.
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

@mgrachten commented on GitHub (Dec 3, 2025):

I did a bisect on the versions, and the issue @csinko and myself are seeing start with 1.0.120.

@mgrachten commented on GitHub (Dec 3, 2025): I did a bisect on the versions, and the issue @csinko and myself are seeing start with 1.0.120.
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

@JarvisPrestidge commented on GitHub (Dec 3, 2025):

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?

@JarvisPrestidge commented on GitHub (Dec 3, 2025): 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: ```jsonc "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?
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

@Lenbok commented on GitHub (Dec 3, 2025):

Sub issue: https://github.com/sst/opencode/issues/4521

@Lenbok commented on GitHub (Dec 3, 2025): Sub issue: https://github.com/sst/opencode/issues/4521
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

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

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.

@ariane-emory commented on GitHub (Dec 10, 2025): 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.
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

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

Yeah, bot was right, I made a personal branch that re-enables Kitty and it does solve the issue.

@ariane-emory commented on GitHub (Dec 10, 2025): Yeah, bot was right, I made a personal branch that re-enables Kitty and it does solve the issue.
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

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

@ariane-emory Commit cc0567553 does not exist. On dev it is this:

Image

which means kitty keyboard is enabled. I don't know where that Timeline of Changes comes from. How did you "re-enable kitty"?

@kommander commented on GitHub (Dec 11, 2025): @ariane-emory Commit `cc0567553` does not exist. On `dev` it is this: <img width="201" height="113" alt="Image" src="https://github.com/user-attachments/assets/dd86bea5-9c5c-40d0-87bc-24dc2258799e" /> which means kitty keyboard is enabled. I don't know where that `Timeline of Changes` comes from. How did you "re-enable kitty"?
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

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

@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).

@ariane-emory commented on GitHub (Dec 11, 2025): @kommander Hah, my bot must have hallucinated a commit. For the 'fix', the useKittyKeyboard line was changed to: ```javascript 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).
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

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

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.

@kommander commented on GitHub (Dec 11, 2025): 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.
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

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

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.

@kommander commented on GitHub (Dec 11, 2025): `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.
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

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

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).

@lcswillems commented on GitHub (Dec 12, 2025): 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).
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

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

shift+enter does not work in all terminals and only with config tweaking in tmux, what terminal are you using?

@kommander commented on GitHub (Dec 12, 2025): `shift+enter` does not work in all terminals and only with config tweaking in tmux, what terminal are you using?
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

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

I'm using the default terminal in VSCode.

@lcswillems commented on GitHub (Dec 12, 2025): I'm using the default terminal in VSCode.
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

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

Yeah shift+enter only works there if you remap it to send \n in you config

@kommander commented on GitHub (Dec 12, 2025): Yeah `shift+enter` only works there if you remap it to send `\n` in you config
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

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

@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.

@ariane-emory commented on GitHub (Dec 12, 2025): @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.
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

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

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 commented on GitHub (Dec 13, 2025): 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.
yindo commented 2026-02-16 17:39:24 -05:00
Author
Owner
Copy Link
Copy Source

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

@kommander No, sorry, iTerm2. I thought you were speaking generally, perhaps I misunderstood.

@ariane-emory commented on GitHub (Dec 13, 2025): @kommander No, sorry, iTerm2. I thought you were speaking generally, perhaps I misunderstood.
yindo commented 2026-02-16 17:39:25 -05:00
Author
Owner
Copy Link
Copy Source

@dhruvkej9 commented on GitHub (Dec 31, 2025):

@kommander shift + enter just sends the message in my case

@dhruvkej9 commented on GitHub (Dec 31, 2025): @kommander shift + enter just sends the message in my case
yindo commented 2026-02-16 17:39:25 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 31, 2025):

@dhruvkej9 what terminal

@rekram1-node commented on GitHub (Dec 31, 2025): @dhruvkej9 what terminal
yindo commented 2026-02-16 17:39:25 -05:00
Author
Owner
Copy Link
Copy Source

@dhruvkej9 commented on GitHub (Dec 31, 2025):

Got it fixed using keybings docs about windows

Windows Terminal but WSL open in it

@dhruvkej9 commented on GitHub (Dec 31, 2025): Got it fixed using keybings docs about windows Windows Terminal but WSL open in it
yindo commented 2026-02-16 17:39:25 -05:00
Author
Owner
Copy Link
Copy Source

@m10rten commented on GitHub (Jan 5, 2026):

Closed #6991, but as 1.1.2 still have the text deletion ctrl+(backspace|del) issue in the /session command.

@m10rten commented on GitHub (Jan 5, 2026): Closed #6991, but as 1.1.2 still have the text deletion ctrl+(backspace|del) issue in the `/session` command.
yindo commented 2026-02-16 17:39:25 -05:00
Author
Owner
Copy Link
Copy Source

@dhruvkej9 commented on GitHub (Jan 5, 2026):

Closed #6991, but as 1.1.2 still have the text deletion ctrl+(backspace|del) issue in the /session command.

ctrl + backspace does not works in opencode anywhere for me

@dhruvkej9 commented on GitHub (Jan 5, 2026): > Closed #6991, but as 1.1.2 still have the text deletion ctrl+(backspace|del) issue in the `/session` command. ctrl + backspace does not works in opencode anywhere for me
yindo commented 2026-02-16 17:39:25 -05:00
Author
Owner
Copy Link
Copy Source

@faileon commented on GitHub (Jan 10, 2026):

hi, since opencode v1.1.8 shift+enter no longer works in my kitty terminal. previous versions works fine. ctrl+j is working in all versions, but my muscle memory is stuck using shift+enter which is rather annoying submitting messages half way thru :)

i poked around the diff between v1.1.7 and v1.1.8 and i believe the primary suspect is the upgrade of opentui to v0.1.70, but i couldnt find anything obvious between v0.1.69 and v0.1.70

EDIT: nevermind, it appears to be fixed in v1.1.11

@faileon commented on GitHub (Jan 10, 2026): hi, since opencode `v1.1.8` shift+enter no longer works in my kitty terminal. previous versions works fine. ctrl+j is working in all versions, but my muscle memory is stuck using shift+enter which is rather annoying submitting messages half way thru :) i poked around the diff between `v1.1.7` and `v1.1.8` and i believe the primary suspect is the upgrade of opentui to `v0.1.70`, but i couldnt find anything obvious between `v0.1.69` and `v0.1.70` **EDIT: nevermind, it appears to be fixed in `v1.1.11`**
yindo commented 2026-02-16 17:39:25 -05:00
Author
Owner
Copy Link
Copy Source

@mykola-dev commented on GitHub (Jan 10, 2026):

hi, since opencode v1.1.8 shift+enter no longer works in my kitty terminal. previous versions works fine. ctrl+j is working in all versions, but my muscle memory is stuck using shift+enter which is rather annoying submitting messages half way thru :)

i poked around the diff between v1.1.7 and v1.1.8 and i believe the primary suspect is the upgrade of opentui to v0.1.70, but i couldnt find anything obvious between v0.1.69 and v0.1.70

EDIT: nevermind, it appears to be fixed in v1.1.11

same in vs code, win10. also broken in intellij terminal

@mykola-dev commented on GitHub (Jan 10, 2026): > hi, since opencode `v1.1.8` shift+enter no longer works in my kitty terminal. previous versions works fine. ctrl+j is working in all versions, but my muscle memory is stuck using shift+enter which is rather annoying submitting messages half way thru :) > > i poked around the diff between `v1.1.7` and `v1.1.8` and i believe the primary suspect is the upgrade of opentui to `v0.1.70`, but i couldnt find anything obvious between `v0.1.69` and `v0.1.70` > > **EDIT: nevermind, it appears to be fixed in `v1.1.11`** same in vs code, win10. also broken in intellij terminal
yindo commented 2026-02-16 17:39:25 -05:00
Author
Owner
Copy Link
Copy Source

@LIHUA919 commented on GitHub (Jan 18, 2026):

After analyzing the codebase and recent fixes, here's a technical summary of the keybind issues and their root causes:

Root Causes Analysis

1. Kitty Keyboard Protocol Dilemma

Current Config: useKittyKeyboard: {} (empty object)

This is a best-effort compromise that:

  • ✅ Avoids doubled key events on older emulators (1.0.120 regression)
  • ❌ Breaks ctrl+m and similar bindings on modern terminals (iTerm2, Kitty)

The Trade-off:

// Before (caused doubled events):
useKittyKeyboard: true  // Full Kitty protocol

// Current (compromise):
useKittyKeyboard: {}    // Partial, breaks some bindings

// Ideal (not possible yet):
// Per-terminal auto-detection without regressions

Why this matters:

  • Kitty protocol allows distinguishing Ctrl+M from Enter
  • Without it, macOS sends \r for both
  • Modern terminals (Kitty, iTerm2) need full protocol
  • Older terminals break with full protocol

2. Shift+Enter IME Conflict (#8275)

The Bug: Shift+Enter was blocked during IME composition

Root Cause:

// Before (broken):
if (event.key === "Enter" && isImeComposing(event)) {
  return  // Blocks Shift+Enter\!
}

if (event.key === "Enter" && event.shiftKey) {
  addPart({ type: "text", content: "\n" })
}

Fix: Move Shift+Enter BEFORE IME check

// After (fixed):
if (event.key === "Enter" && event.shiftKey) {
  addPart({ type: "text", content: "\n" })  // Always works
  return
}

if (event.key === "Enter" && isImeComposing(event)) {
  return
}

This fixed the v1.1.8 regression reported in comments.

3. Terminal-Specific Issues

Terminal Problem Workaround
VSCode Shift+Enter sends wrong code Configure to send \n
Windows Terminal ctrl+backspace, ctrl+c Use WSL or keybinds config
Warp Alt+options don't work Terminal limitation
Older emulators Doubled events Kitty protocol disabled

Recent Fixes

  1. #8275 - Shift+Enter IME conflict (v1.1.11)
  2. #7108 - Expanded keybinds documentation
  3. Kitty flag - Made configurable (commit 3750902d6)

Recommendations

For Users:

  • Modern terminals (Kitty, iTerm2): Use keybinds config to remap broken keys
  • VSCode: Configure terminal to send proper codes
  • Windows: Use WSL or follow https://opencode.ai/docs/keybinds/

For Maintainers:

Consider making `useKittyKeyboard** a user-configurable option:

{
  "keybinds": {
    "useKittyKeyboard": true
  }
}

This would let users choose based on their terminal.

Status

Many issues have been fixed, but the fundamental terminal diversity problem remains. The Kitty protocol compromise is the best solution for now, but it means some bindings won't work on all terminals.

@LIHUA919 commented on GitHub (Jan 18, 2026): After analyzing the codebase and recent fixes, here's a technical summary of the keybind issues and their root causes: ## Root Causes Analysis ### 1. Kitty Keyboard Protocol Dilemma **Current Config:** `useKittyKeyboard: {}` (empty object) This is a **best-effort compromise** that: - ✅ Avoids doubled key events on older emulators (1.0.120 regression) - ❌ Breaks `ctrl+m` and similar bindings on modern terminals (iTerm2, Kitty) **The Trade-off:** ```typescript // Before (caused doubled events): useKittyKeyboard: true // Full Kitty protocol // Current (compromise): useKittyKeyboard: {} // Partial, breaks some bindings // Ideal (not possible yet): // Per-terminal auto-detection without regressions ``` **Why this matters:** - Kitty protocol allows distinguishing `Ctrl+M` from `Enter` - Without it, macOS sends `\r` for both - Modern terminals (Kitty, iTerm2) need full protocol - Older terminals break with full protocol ### 2. Shift+Enter IME Conflict (#8275) **The Bug:** Shift+Enter was blocked during IME composition **Root Cause:** ```typescript // Before (broken): if (event.key === "Enter" && isImeComposing(event)) { return // Blocks Shift+Enter\! } if (event.key === "Enter" && event.shiftKey) { addPart({ type: "text", content: "\n" }) } ``` **Fix:** Move Shift+Enter BEFORE IME check ```typescript // After (fixed): if (event.key === "Enter" && event.shiftKey) { addPart({ type: "text", content: "\n" }) // Always works return } if (event.key === "Enter" && isImeComposing(event)) { return } ``` This fixed the v1.1.8 regression reported in comments. ### 3. Terminal-Specific Issues | Terminal | Problem | Workaround | |----------|---------|------------| | **VSCode** | Shift+Enter sends wrong code | Configure to send `\n` | | **Windows Terminal** | ctrl+backspace, ctrl+c | Use WSL or keybinds config | | **Warp** | Alt+options don't work | Terminal limitation | | **Older emulators** | Doubled events | Kitty protocol disabled | ## Recent Fixes 1. **#8275** - Shift+Enter IME conflict (v1.1.11) 2. **#7108** - Expanded keybinds documentation 3. **Kitty flag** - Made configurable (commit 3750902d6) ## Recommendations ### For Users: - **Modern terminals** (Kitty, iTerm2): Use keybinds config to remap broken keys - **VSCode**: Configure terminal to send proper codes - **Windows**: Use WSL or follow https://opencode.ai/docs/keybinds/ ### For Maintainers: Consider making `useKittyKeyboard\** a user-configurable option: ```json { "keybinds": { "useKittyKeyboard": true } } ``` This would let users choose based on their terminal. ## Status Many issues have been fixed, but the fundamental **terminal diversity problem** remains. The Kitty protocol compromise is the best solution for now, but it means some bindings won't work on all terminals.
yindo commented 2026-02-16 17:39:25 -05:00
Author
Owner
Copy Link
Copy Source

@aspiers commented on GitHub (Jan 18, 2026):

I submitted feature request #9234 and corresponding PR #6778 for adding readline- / Emacs-style keybindings for text transformations and pasting text which was previously cut. @rekram1-node I think this belongs on the above list, right?

@aspiers commented on GitHub (Jan 18, 2026): I submitted feature request #9234 and corresponding PR #6778 for adding readline- / Emacs-style keybindings for text transformations and pasting text which was previously cut. @rekram1-node I think this belongs on the above list, right?
yindo commented 2026-02-16 17:39:25 -05:00
Author
Owner
Copy Link
Copy Source

@topmask commented on GitHub (Jan 21, 2026):

┌ Add credential
│
◆ Select provider
│ Search: _
│ ● OpenCode Zen (recommended)
│ ○ Anthropic
│ ○ GitHub Copilot
│ ○ OpenAI
│ ○ Google
│ ...
│ ↑/↓ to select • Enter: confirm • Type: to search

I cannot select an account to log in using the up and down arrow keys.
I cannot focus on the upper level.

@topmask commented on GitHub (Jan 21, 2026): ┌ Add credential │ ◆ Select provider │ Search: _ │ ● OpenCode Zen (recommended) │ ○ Anthropic │ ○ GitHub Copilot │ ○ OpenAI │ ○ Google │ ... │ ↑/↓ to select • Enter: confirm • Type: to search I cannot select an account to log in using the up and down arrow keys. I cannot focus on the upper level.
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 discussion
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#3262
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?