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

EDITOR=nvim hangs & some characters seem to pass to the opencode instead of nvim #2788

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

Originally created by @Pivert on GitHub (Nov 11, 2025).

Originally assigned to: @kommander on GitHub.

Description

Using opencode v1.0.57, and
export EDITOR=/usr/local/bin/nvim (nvim 0.11.2)

When I switch to nvim editor (+x e)

The vim editor seems to grab less than half of the key stroke / hangs...

When we can finally type the :q! in the nvim editor, we can see that some characters were inserted in the opencode UI such as ":q!::::qqqqq" (the number of tries we had to type to finally exit nvim)

It seems both foreground nvim and background opencode fight to get the keyboard.

The problem does not occur with old v0.5.13 but seems to occur from version 1.0.0.

OpenCode version

v1.0.57

Steps to reproduce

  1. switch to nvim editor (+x e)
  2. try to edit or enter some text
  3. The nvim freezes every second or so. It gets difficult even to quit it (:q!)

Screenshot and/or share link

No response

Operating System

Kubuntu 24.04 LTS

Terminal

Konsole

Originally created by @Pivert on GitHub (Nov 11, 2025). Originally assigned to: @kommander on GitHub. ### Description Using opencode v1.0.57, and export EDITOR=/usr/local/bin/nvim (nvim 0.11.2) When I switch to nvim editor (<ctrl>+x e) The vim editor seems to grab less than half of the key stroke / hangs... When we can finally type the :q! in the nvim editor, we can see that some characters were inserted in the opencode UI such as ":q!::::qqqqq" (the number of tries we had to type to finally exit nvim) It seems both foreground nvim and background opencode fight to get the keyboard. The problem does not occur with old v0.5.13 but seems to occur from version 1.0.0. ### OpenCode version v1.0.57 ### Steps to reproduce 1. switch to nvim editor (<ctrl>+x e) 2. try to edit or enter some text 3. The nvim freezes every second or so. It gets difficult even to quit it (:q!) ### Screenshot and/or share link _No response_ ### Operating System Kubuntu 24.04 LTS ### Terminal Konsole
yindo added the opentuibug labels 2026-02-16 17:37:15 -05:00
yindo closed this issue 2026-02-16 17:37:16 -05:00
yindo commented 2026-02-16 17:37:16 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 11, 2025):

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

  • #1213: Similar issue with neovim-remote failing silently when using /editor command in Neovim terminal, also causing editor functionality problems
  • #3359: Editor not working well with input not going to prompt box properly
  • #3311: Switching to editor messes up the TUI, similar to characters passing through to OpenCode interface
  • #2257: OpenCode displays/behaves incorrectly when launched inside Neovim's terminal with rendering issues

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Nov 11, 2025): This issue might be a duplicate of existing issues. Please check: - #1213: Similar issue with neovim-remote failing silently when using `/editor` command in Neovim terminal, also causing editor functionality problems - #3359: Editor not working well with input not going to prompt box properly - #3311: Switching to editor messes up the TUI, similar to characters passing through to OpenCode interface - #2257: OpenCode displays/behaves incorrectly when launched inside Neovim's terminal with rendering issues Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:37:16 -05:00
Author
Owner
Copy Link
Copy Source

@Pivert commented on GitHub (Nov 11, 2025):

So far, I did try:

  • Downgrade opencode to 0.5.13 => It fixes the problem OK
  • Using vim : export EDITOR=/usr/bin/vim.nox => NOK
  • Changing TERM to xterm => NOK
  • Removing the $HOME/.config/nvim to reset the nvim profile => NOK
  • Using another terminal than konsole such as kitty => NOK
@Pivert commented on GitHub (Nov 11, 2025): So far, I did try: - Downgrade opencode to 0.5.13 => It fixes the problem OK - Using vim : export EDITOR=/usr/bin/vim.nox => NOK - Changing TERM to xterm => NOK - Removing the $HOME/.config/nvim to reset the nvim profile => NOK - Using another terminal than konsole such as kitty => NOK
yindo commented 2026-02-16 17:37:16 -05:00
Author
Owner
Copy Link
Copy Source

@lennox-davidlevy commented on GitHub (Nov 20, 2025):

I am experiencing this same issue on v1.0.80.

After entering editor mode via /editor, input is erratic. Keystrokes are frequently missed or require multiple presses to register (behaving like a race condition on stdin), making the editor unusable until I kill the process.

Environment:

  • OS: Linux Fedora 42
  • Terminal: Ghostty 1.2.3-1.fc42
  • Neovim: v0.12.0-dev+1665-69b286c3b
@lennox-davidlevy commented on GitHub (Nov 20, 2025): I am experiencing this same issue on **v1.0.80**. After entering editor mode via `/editor`, input is erratic. Keystrokes are frequently missed or require multiple presses to register (behaving like a race condition on stdin), making the editor unusable until I kill the process. **Environment:** - **OS:** Linux Fedora 42 - **Terminal:** Ghostty `1.2.3-1.fc42` - **Neovim:** `v0.12.0-dev+1665-69b286c3b`
yindo commented 2026-02-16 17:37:16 -05:00
Author
Owner
Copy Link
Copy Source

@fnumatic commented on GitHub (Nov 20, 2025):

Same issue on version 1.0.80

I'm encountering the exact same problem as described in the original issue, still present in v1.0.80.

Description

After entering editor mode using the /editor command, keyboard input becomes extremely erratic:

  • Many keystrokes are completely ignored
  • Some keys require multiple presses (sometimes 3–10 times) before they register

Environment

  • OS: Ubuntu 25.10 (Questing Quokka)
  • Terminal: Ptyxis 49.1 (GNOME terminal emulator)
  • Affected editors:
    • Neovim: NVIM v0.11.5 → Not working
    • Vim: VIM - Vi IMproved 9.1 → Not working
    • nano: GNU nano 8.4 → Works perfectly
@fnumatic commented on GitHub (Nov 20, 2025): **Same issue on version 1.0.80** I'm encountering the exact same problem as described in the original issue, still present in **v1.0.80**. ### Description After entering editor mode using the `/editor` command, keyboard input becomes extremely erratic: - Many keystrokes are completely ignored - Some keys require multiple presses (sometimes 3–10 times) before they register ### Environment - **OS**: Ubuntu 25.10 (Questing Quokka) - **Terminal**: Ptyxis 49.1 (GNOME terminal emulator) - **Affected editors**: - Neovim: `NVIM v0.11.5` → **Not working** - Vim: `VIM - Vi IMproved 9.1` → **Not working** - nano: `GNU nano 8.4` → **Works perfectly**
yindo commented 2026-02-16 17:37:16 -05:00
Author
Owner
Copy Link
Copy Source

@gabrielmontagne commented on GitHub (Nov 20, 2025):

I have the same issue with plain VIM (8.2 and 9.0); noticied it today running OC 1.0.80.

If I rollback just to 1.0.77 it seems to work ok for me.

@gabrielmontagne commented on GitHub (Nov 20, 2025): I have the same issue with plain VIM (8.2 and 9.0); noticied it today running OC 1.0.80. If I rollback just to 1.0.77 it seems to work ok for me.
yindo commented 2026-02-16 17:37:16 -05:00
Author
Owner
Copy Link
Copy Source

@lennox-davidlevy commented on GitHub (Nov 20, 2025):

@gabrielmontagne I can confirm, rolling back to 1.0.77 is working for me as well.

@lennox-davidlevy commented on GitHub (Nov 20, 2025): @gabrielmontagne I can confirm, rolling back to 1.0.77 is working for me as well.
yindo commented 2026-02-16 17:37:16 -05:00
Author
Owner
Copy Link
Copy Source

@fnumatic commented on GitHub (Nov 20, 2025):

for me v1.0.78 is the last good version
v1.0.79 starts to fail

probably:
https://github.com/sst/opencode/commit/9c85a37811bf0303cb166ca2dd927700bf8c263e

@fnumatic commented on GitHub (Nov 20, 2025): for me v1.0.78 is the last good version v1.0.79 starts to fail probably: https://github.com/sst/opencode/commit/9c85a37811bf0303cb166ca2dd927700bf8c263e
yindo commented 2026-02-16 17:37:16 -05:00
Author
Owner
Copy Link
Copy Source

@bowmanjd commented on GitHub (Nov 21, 2025):

@veracioux may have the right idea to fix this in opentui, but I also offer https://github.com/sst/opencode/pull/4595 in the theory that it is a good idea to turn off raw mode for the duration of the editor session. In other words, give the editor the keyboard input. (Edit: After further testing, I closed that PR, as it was not effective after all. The issue on my machine came and went, causing me to think this had fixed it when in fact it did not.)

@bowmanjd commented on GitHub (Nov 21, 2025): @veracioux may have the right idea to fix this in opentui, but I also offer https://github.com/sst/opencode/pull/4595 in the theory that it is a good idea to turn off raw mode for the duration of the editor session. In other words, give the editor the keyboard input. (Edit: After further testing, I closed that PR, as it was not effective after all. The issue on my machine came and went, causing me to think this had fixed it when in fact it did not.)
yindo commented 2026-02-16 17:37:16 -05:00
Author
Owner
Copy Link
Copy Source

@the-coding-doggo commented on GitHub (Nov 21, 2025):

Same issue on version 1.0.85

I'm encountering the exact same problem as described in the original issue, still present in v1.0.80.

Description
After entering editor mode using the /editor command, keyboard input becomes extremely erratic:
Many keystrokes are completely ignored, then after closing edior TUI crashes
Some keys require multiple presses (sometimes 3–10 times) before they register

Environment
OS: 6.17.8-arch1-1 -- Hyprland
Terminal: foot
Affected editors:
Neovim: NVIM v0.11.5 → Not working

Temporary fix
export EDITOR="foot -e nvim" --> It opens nvim in a different terminal and reopens the tui at terminal close

@the-coding-doggo commented on GitHub (Nov 21, 2025): Same issue on version 1.0.85 I'm encountering the exact same problem as described in the original issue, still present in v1.0.80. **Description** After entering editor mode using the /editor command, keyboard input becomes extremely erratic: Many keystrokes are completely ignored, then after closing edior TUI crashes Some keys require multiple presses (sometimes 3–10 times) before they register **Environment** OS: 6.17.8-arch1-1 -- Hyprland **Terminal:** foot **Affected editors:** Neovim: NVIM v0.11.5 → Not working **Temporary fix** export EDITOR="foot -e nvim" --> It opens nvim in a different terminal and reopens the tui at terminal close
yindo commented 2026-02-16 17:37:16 -05:00
Author
Owner
Copy Link
Copy Source

@hamidi-dev commented on GitHub (Nov 23, 2025):

same issue here on MacOS + Iterm2 + tmux. And in Ubuntu WSL + tmux.
I am now also stuck on 1.0.78, the last "good" version

@hamidi-dev commented on GitHub (Nov 23, 2025): same issue here on MacOS + Iterm2 + tmux. And in Ubuntu WSL + tmux. I am now also stuck on 1.0.78, the last "good" version
yindo commented 2026-02-16 17:37:16 -05:00
Author
Owner
Copy Link
Copy Source

@bowmanjd commented on GitHub (Nov 23, 2025):

Temporary fix export EDITOR="foot -e nvim" --> It opens nvim in a different terminal and reopens the tui at terminal close

@hamidi-dev and others, don't forget the good workaround from @the-coding-doggo -- if you set VISUAL or EDITOR to a terminal command that launches your editor, the experience is pretty smooth.

That is, just while we wait a short while for a fix to land... The PR from @veracioux was merged into opentui yesterday and is available in opentui 0.1.49. So, once opencode is using opentui 0.1.49, all will be well.

For the impatient, bun add @opentui/core@0.1.49 @opentui/solid@0.1.49 in the packages/opencode directory works wonders.

@bowmanjd commented on GitHub (Nov 23, 2025): > **Temporary fix** export EDITOR="foot -e nvim" --> It opens nvim in a different terminal and reopens the tui at terminal close @hamidi-dev and others, don't forget the good workaround from @the-coding-doggo -- if you set VISUAL or EDITOR to a terminal command that launches your editor, the experience is pretty smooth. That is, just while we wait a short while for a fix to land... The PR from @veracioux was merged into opentui yesterday and is available in opentui 0.1.49. So, once opencode is using opentui 0.1.49, all will be well. For the impatient, `bun add @opentui/core@0.1.49 @opentui/solid@0.1.49` in the `packages/opencode` directory works wonders.
yindo commented 2026-02-16 17:37:16 -05:00
Author
Owner
Copy Link
Copy Source

@kommander commented on GitHub (Nov 23, 2025):

Is live now with 1.0.106, better?

@kommander commented on GitHub (Nov 23, 2025): Is live now with 1.0.106, better?
yindo commented 2026-02-16 17:37:16 -05:00
Author
Owner
Copy Link
Copy Source

@bowmanjd commented on GitHub (Nov 23, 2025):

Yes, all better now! Thank you so much.

@bowmanjd commented on GitHub (Nov 23, 2025): Yes, all better now! Thank you so much.
yindo commented 2026-02-16 17:37:16 -05:00
Author
Owner
Copy Link
Copy Source

@fnumatic commented on GitHub (Nov 24, 2025):

v1.0.106 fixed, thank you

@fnumatic commented on GitHub (Nov 24, 2025): v1.0.106 fixed, thank you
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#2788
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?