bug: potentially targets zombie `opencode` processes

[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

[NickvanDyke]

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.