Repository navigation
service: per-user background service binds a machine-global port — multi-user Windows collision #62749
Description
service: per-user background service binds a machine-global port — multi-user Windows collision
Summary
The shared background service is per-user, but its listening port is a fixed, machine-global default (28894 on Windows). On a multi-user Windows machine only one profile's service can hold the port at a time, so a second profile signed in concurrently cannot start opencode — and there is no supported way to change or derive the port per user.
Environment
- opencode version: 2.2.6 (Windows, affected machine; service-command surface cross-checked on 2.1.1)
- OS: Windows 10 22H2 (10.0.19045), multi-user machine with several local profiles
- Terminal: Windows Terminal / PowerShell 5.1 (reproduces in any terminal)
- Shell: PowerShell
- Install/channel: latest, official Windows x64 zip (opencode.ai update channel), installed machine-wide
- Active plugins: none
Reproduction
- On a Windows machine, have two local user profiles A and B, both with opencode on PATH.
- Keep both signed in simultaneously: sign in to A, then use "Switch user" to sign in to B (both sessions stay alive).
- In A, run
opencode— its background service starts and binds the fixed service port. - In B, run
opencode.
Expected Behavior
Per the docs the background server is "one shared background server for your user account" — per user. Profiles A and B should each get a working service concurrently, either by deriving the port per user or by exposing a configurable port for the auto-started service.
Actual Behavior
In B, opencode fails to start with:
service port 28894 is in use by another process
B can only proceed after A's service is killed (taskkill) or A signs out. Reproduces consistently whenever two profiles have live sessions; a service left behind by a disconnected "switch user" session also holds the port for the next profile that signs in.
Additional Context
- No override exists:
opencode serviceexposes only start / restart / status / stop / get / set / unset (verified on 2.2.6), andopencode serve --portapplies only to manually started servers, not the auto-started shared service. - The mismatch: service registration and config are per-user (
~/.local/state/opencode/service.json,~/.config/opencode/service.json), but the port is machine-global. - Verified workaround:
opencode service set disabled trueper profile. Every opencode start then runs its own embedded instance with no TCP listener at all (confirmed with a socket scan during a run — zero new listeners). Sessions and history are unaffected; pairing is unavailable while disabled. This works, but out-of-the-box multi-user use is broken until each profile knows the trick. - Suggested fixes: derive the service port per user (e.g., a stable hash of the user's home directory), or add a
service set portkey. Either restores concurrent multi-user use on one machine. - Frequency: consistent on any multi-user Windows machine with concurrent sessions.
Activity
opencodejr commentedon Nov 8, 2026
Thanks for the detailed report and for checking a workaround. I think this is a duplicate of #50672, which tracks the same root cause. The managed service's default port is fixed for each channel (28894 on Windows) and has no per-user part, while the service registration and config are per user. So a second user signed in at the same time can't bind the port.
Possible duplicates and closely related issues, ordered by likelihood:
A simpler workaround than disabling the service: the service config does have a
portkey. In the second profile, runopencode service set port <free port>(for exampleopencode service set port 28895), thenopencode service restart. Each profile then gets its own service, and pairing still works.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
mariaa144 commentedon Nov 8, 2026
Correction after further testing — part of the report above is wrong: a port override does exist and works in both 2.1.1 and 2.2.6:
opencode service set port 12345writes
"port": 12345into the per-user~/.config/opencode/service.json, and the background service binds that port on next start (verified: the listener shows up on exactly the configured port). Per-profile unique ports are therefore a viable workaround that keeps the shared service.What still stands:
port(andhostname) keys appear undocumented: neither the troubleshooting page's service section nor the CLI docs mentionservice set port— the documented examples cover onlycorsanddisabled. That documentation gap is exactly why this report initially claimed no override existed.So the ask narrows to: derive the default service port per user (e.g., a stable hash of the home directory), or at minimum document
service set port(andhostname) for multi-user Windows machines. Apologies for the inaccurate "no override exists" claim in the body — posting this correction rather than silently editing.opencodejr commentedon Nov 8, 2026
Thanks for testing further and posting the correction. Glad
opencode service set portworks for you.I'd still treat what remains as part of #50672. That issue tracks the default service port being machine-wide while the service is per user. On the current
devbranch,defaultPort()still returns a fixed port for each channel (28894 on Windows) with no per-user part. Changing that default is exactly what #50672 is about, so please follow and add to that issue. Your multi-user Windows case is a useful data point there.On the docs:
portandhostnameare documented, on the Configure section of the Web docs page, next to the table of default ports (opencode service set port 49374,opencode service set hostname 0.0.0.0). You're right that the troubleshooting page and theserviceexamples on the CLI commands page don't mention them. Also, the full error should name the fix, for example:Managed service port 28894 on 127.0.0.1 is already in use by <process>. Configure another port with \opencode service set port ` and start the service again.If you only ever see the shorterservice port 28894 is in use by another processtext, the hint is getting lost somewhere. Please say so here or on #50672, ideally with the matching line fromopencode.log`.Related, ordered by likelihood:
Unless there's something here that #50672 doesn't cover, the bot will still close this issue as a duplicate as planned.
Bbk1AtJJF8 commentedon Nov 8, 2026
While
opencode service set portallows for a manual workaround, we should updatedefaultPort()in the service initialization logic to incorporate a hash of the user's SID or profile path to ensure a unique, collision-free default port for multi-user environments.opencodejr commentedon Nov 9, 2026
Closing this as a duplicate of #50672, as planned. Thanks again for the detailed report and for posting the correction. The remaining problem is that the default service port (28894 on Windows) is the same for every user on the machine, and #50672 tracks that. Please follow it there, and feel free to add your multi-user Windows case. Until it's fixed, running
opencode service set port <free port>in each additional profile, thenopencode service restart, gives every user their own service.