feature: easier way to just specify the server endpoint

[marcelbeumer]

Did you check the docs?

• I have read all the docs

Is your feature request related to a problem? Please describe.

I like to run my opencode in a sandbox with opencode serve. Maybe on http://127.0.0.1:4069, maybe elsewhere. I notice the plugin tries to be smart about running servers, but right now to make this work I need to do:

1. Start opencode with opencode serve --port because without --port the plugin won't detect the process
2. Add a configuration block for require("opencode.terminal").start|toggle on with ("opencode attach http://127.0.0.1:4096") instea of ("opencode --port")

And I guess it won't work with opencode instances on other hosts at all.

Why not just provide and endpoint via the config, and when its empty, try to start a own server (or not; i can start my own)? No smart process finding, etc.

Describe the solution you'd like

Provide and endpoint via the config, and when its empty, try to start a own server (or not; i can start my own)? No smart process finding, etc.

Describe alternatives you've considered

Not much

Additional context

No response

[nickjvandyke]

without --port the plugin won't detect the process

Ah, with just opencode, --port is required to expose the server. I didn't realize that serve does that too! Changing the detection to pick that up should be easy.

I think that would address 2. as well? start is irrelevant when a server is found.

I'd definitely like to make the server location more flexible. Probably via opts.server.origin? I just need time to consider how it interplays with the existing server discovery and starting logic.

[nickjvandyke]

Does opencode serve even work with requests from the plugin? I see it receive requests with --print-logs, but it doesn't actually do anything (e.g. add requested comments)

[nickjvandyke]

And I guess it won't work with opencode instances on other hosts at all.

I overlooked this initially. You mean with no TUI at all, right? That'd require us to use a different (and more difficult) API entirely to send directly to the server. It also re-introduces the problem that we can't know the "active" session, and have to best-guess it as the most recently interacted one. I guess I'll have to see how opencode usage evolves.

But I think we can at least accommodate sending prompts to a TUI attached to a remote server? It depends. I wonder if we are meant to send TUI requests to the server still, or if the attached TUI process exposes its own server.