Repository navigation
service: hardcoded default port 49374 with no fallback and a silent hang when it's unavailable #52234
Description
Activity
This issue doesn't fully meet our contributing guidelines.
What needs to be fixed:
- Please condense the unusually long, repetitive description. Keep the concise failure summary, reproduction steps, and relevant environment details, and remove repeated port-conflict explanations.
Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
- #50672: reports the same hard-coded port 49374 conflict and background-service startup failure when another client shares the loopback.
- #49009: reports a port bind conflict being hidden behind a generic background-service startup timeout.
If you believe this was flagged incorrectly, please let a maintainer know.
Thanks for the update. The description still repeats the same port-conflict/fallback explanation across Summary, Actual Behavior, and Additional Context, and Suggested Fixes restates Expected Behavior. Please condense those sections so each fact appears once while keeping the reproduction steps and relevant environment details.
Thanks for updating the issue with the reproduction steps and environment details!
Related to #50672 (same underlying cause: hard-coded
49374, no port fallback). Keeping this open as a distinct report because it covers two cases that issue does not:- WSL2/Hyper-V reserved ranges. The Windows host can dynamically reserve a range that includes
49374, so the port is unbindable even when nothing else is listening on it. - Desktop app vs. CLI service on the same host. Both want the same default port, so whichever starts second hangs with no message.
#50672 describes the same defect for the shared-loopback / second-client case.
Reacted by alekseyHunter- WSL2/Hyper-V reserved ranges. The Windows host can dynamically reserve a range that includes
Bump
Summary
When the background service's default port (
49374on release channels) is unavailable, the TUI hangs onStarting background server...indefinitely instead of choosing another port or reporting the bind failure. On WSL2/Hyper-V this happens unpredictably because the host can reserve ranges covering that port.Environment
/root/.opencode/bin/opencode)/bin/bash,TERM=xterm-256color-opencode-pty,cc-safety-net@latest; CLI pluginsopencode-stats,ssh-remote,devicesReproduction
49374unbindable (another listener, or a WSL/Hyper-V dynamic port exclusion covering it).opencode.Starting background server...and never reaches a session.Expected Behavior
Bind a free port automatically, or fail fast with a visible error naming the port and the
opencode service set port <port>remedy.Actual Behavior
The child service emits the real error:
…but the client captures that stderr, prints only
Starting background server..., and retries with backoff (spawnDelay 5000,maxSpawnDelay 30000,promiseTimeout 120000).Additional Context
49374,localreturns49375, others derive a value; there is no fallback or port scan.service setacceptsport, butservice set --helpomits it and the Network docs cover onlyservice set env.