bug: provider's `opencode` process orphans when stopping

[PhantomYdn]

Did you check docs and existing issues?

• I have read all the plugin docs
• I have searched the existing issues
• I have searched the existing opencode issues

Operating system/version

MacOS 26.2

:checkhealth opencode output

1 ============================================================================== 2 opencode: 2 ⚠️ 3 4 opencode.nvim 5 - ✅ OK nvim version: 0.11.5. 6 - ✅ OK opencode.nvim git commit hash: 9356782. 7 - ✅ OK vim.g.opencode_opts: { 8 provider = { 9 enabled = "tmux", 10 tmux = { 11 options = "-h -p 35" 12 } 13 } 14 } 15 16 opencode.nvim [binaries] 17 - ✅ OK opencode available with version 1.0.220. 18 - ✅ OK curl available. 19 - ✅ OK pgrep available. 20 - ✅ OK lsof available. 21 22 opencode.nvim [snacks] 23 - ✅ OK snacks.input is enabled: ask() will be enhanced. 24 - ✅ OK snacks.picker is enabled: select() will be enhanced. 25 26 opencode.nvim [providers] 27 - ✅ OK Configured opencode provider: tmux. 28 - ✅ OK The snacks provider is available. 29 - ⚠️ WARNING The kitty provider is not available — KITTY_LISTEN_ON environment variable is not set. 30 - ADVICE: 31 - Enable remote control in kitty. 32 - ⚠️ WARNING The wezterm provider is not available — wezterm executable not found in $PATH. 33 - ADVICE: 34 - Install wezterm and ensure it's in your $PATH. 35 - ✅ OK The tmux provider is available. 36 - ✅ OK The terminal provider is available.

Describe the bug

I have multiple tmux sessions with nvim and opencode.nvim. And for some instances - all it fine, but for one - it just can't find openned opencode by themself. Restart doesn't work. All commands sent to opencode from nvim just doesn't have any effect.

Steps To Reproduce

1. Hard to say: it doesn't work at one place. And I don't know how to troubleshoot.

Expected Behavior

Should be connected always - especially if opencode was started by the plugin.

[PhantomYdn]

I thought that it might be due to fact that pane id was not found. But indeed the following code show proper and valid pane id. So there is some other reason why opencode.nvim can't send to opencode prompts...

:lua print(require("opencode.config").provider.pane_id)

[PhantomYdn]

I found a root cause: one of previous instances of opencode become stale in background when nvim quit. Killing that phantom process helped. But - seems that there is some room for optimization of this plugin: with the aid of pane id it's possible to find exact opencode process which is running at a pane.

[PhantomYdn]

I drafted possible solution here #119

[nickjvandyke]

Thanks for this! Provider-specific opencode finding has crossed my mind before. And then probably move the global get_port behavior to a new "external" provider. The reduced reliability on CWD to find opencode's port could help #104 too.

First though I wonder if we should fix this broader issue?

one of previous instances of opencode become stale in background when nvim quit

You're using the tmux provider right? plugin/provider.lua tries to provider.stop() on VimLeave. But maybe it needs tweaking to increase reliability?

[PhantomYdn]

I suspect that "hanging" problem might be a problem of opencode itself. I saw curl subprocess for that hanging opencode. It's possible to work more on proper graceful shutdown - but, imho, it might lead to more side-effects. Or... At least it's possible to notify user about zombie process: at VimLeave, and when trying to connect.

[itai-delphos]

I'm experiencing a similar issue with the tmux provider. When I have multiple tmux windows with Neovim instances, using prompt("@this") sometimes sends the prompt to an OpenCode instance in a different tmux window instead of the one in my current window.
I think this is related because the root cause seems to be the same: when using the tmux provider, OpenCode runs in a separate tmux pane (not as a child of Neovim), so the server selection logic in find_server_inside_nvim_cwd() can't properly identify which OpenCode belongs to which Neovim instance. It ends up picking the wrong server when multiple OpenCode instances exist with matching CWDs.

[nickjvandyke]

@itai-delphos #119 should fix that! I just need the time to review and build on it.

Changed the issue title to hopefully better represent this specific root issue.

[itai-delphos]

@itai-delphos #119 should fix that! I just need the time to review and build on it.

Changed the issue title to hopefully better represent this specific root issue.

Will you merge it? I don't really want to use a fork that falls behind the main release.