Skip to content

Comments

fix(tmux): use pane PID to find correct opencode server port#119

Open
PhantomYdn wants to merge 1 commit intonickjvandyke:mainfrom
PhantomYdn:main
Open

fix(tmux): use pane PID to find correct opencode server port#119
PhantomYdn wants to merge 1 commit intonickjvandyke:mainfrom
PhantomYdn:main

Conversation

@PhantomYdn
Copy link

When multiple opencode instances share the same CWD, the previous CWD-based discovery could select the wrong instance. This was particularly problematic with tmux provider since opencode processes spawned via tmux are not descendants of Neovim.

Changes:

  • Add get_port() method to provider interface
  • Implement get_port() for tmux provider using pane PID tracing
  • Add process utilities (get_descendants, get_listening_port)
  • Check provider's get_port() before falling back to CWD discovery
  • Other providers return nil (fallback to existing behavior)

Fixes #118

When multiple opencode instances share the same CWD, the previous
CWD-based discovery could select the wrong instance. This was
particularly problematic with tmux provider since opencode processes
spawned via tmux are not descendants of Neovim.

Changes:
- Add get_port() method to provider interface
- Implement get_port() for tmux provider using pane PID tracing
- Add process utilities (get_descendants, get_listening_port)
- Check provider's get_port() before falling back to CWD discovery
- Other providers return nil (fallback to existing behavior)

Fixes nickjvandyke#118
@nickjvandyke
Copy link
Owner

Thanks for proofing this out! I think it's the correct solution for #118. I hope to review it soon.

I'm also curious which other providers could surface their opencode PID. Not necessarily for this PR, but I'd like this pattern to be generally useful if we incorporate it.

@nickjvandyke nickjvandyke force-pushed the main branch 6 times, most recently from de5f1cc to 5de2380 Compare February 2, 2026 16:31
nickjvandyke added a commit that referenced this pull request Feb 23, 2026
…e server option

The plugin's purpose is _interfacing_ with `opencode` - running it is
just a neat convenience. But as the plugin has grown (yay!), that "neat
convenience" has become endless quirks and the majority of maintenance
work. Unfortunately, I'm forced to make the difficult call to remove
providers to make time for more useful work.

I retained the embedded terminal (and instructions to integrate e.g.
`snacks.terminal`) because it's useful to have _some_ way to get
started. But beyond that, it's not practical to service every user's
preferences. And anyway, it's bad UX to ask them to understand a new way
of using/configuring their terminal environment. It may make sense as
its own plugin (and feel free to extract the code for that!), but as far
as `opencode.nvim` goes, it is far, far out of scope.

Thank you for understanding! I look forward to bringing you more cool
features :D

#118
#180
#166
#104
#150
#119
#105
@nickjvandyke nickjvandyke force-pushed the main branch 2 times, most recently from 66f04d7 to a4dff90 Compare February 24, 2026 19:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug: provider's opencode process orphans when stopping

2 participants