Repository navigation
service: hardcoded default port 49374 with no fallback and a silent hang when it's unavailable #52234
Description
Summary
When the background service's default port (49374 on release channels) is unavailable, the TUI hangs on Starting 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
- opencode v2.0.20, latest (binary at
/root/.opencode/bin/opencode) - Linux 5.15 WSL2 (Windows host),
/bin/bash,TERM=xterm-256color - Plugins:
-opencode-pty,cc-safety-net@latest; CLI pluginsopencode-stats,ssh-remote,devices
Reproduction
- Make
49374unbindable (another listener, or a WSL/Hyper-V dynamic port exclusion covering it). - Run
opencode. - The TUI stays on
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:
Managed service port ${port} on ${host} is already in use by another process.
Configure another port with `opencode service set port <port>` and start the service again.
…but the client captures that stderr, prints only Starting background server..., and retries with backoff (spawnDelay 5000, maxSpawnDelay 30000, promiseTimeout 120000).
Additional Context
- v2.0.20 hard-codes the port: release channels return
49374,localreturns49375, others derive a value; there is no fallback or port scan. - The override is undocumented:
service setacceptsport, butservice set --helpomits it and the Network docs cover onlyservice set env. - The desktop app collides with the CLI service on the same port and hangs identically.
- Possibly related: service: hardcoded default port 49374 locks out any second client on shared loopback (multi-user/WSL mirrored), surfacing only a generic timeout #50672, cli: background service startup reports generic timeout, hiding port-in-use root cause #49009.
Activity
github-actions commentedon Sep 30, 2026
This issue doesn't fully meet our contributing guidelines.
What needs to be fixed:
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:
If you believe this was flagged incorrectly, please let a maintainer know.
github-actions commentedon Sep 30, 2026
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.
github-actions commentedon Sep 30, 2026
Thanks for updating the issue with the reproduction steps and environment details!
CyberTodBG commentedon Sep 30, 2026
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:49374, so the port is unbindable even when nothing else is listening on it.#50672 describes the same defect for the shared-loopback / second-client case.
alekseyHunter commentedon Oct 7, 2026
Bump
neriousy commentedon Oct 19, 2026
A few follow-ups to help separate the causes behind this message:
%USERPROFILE%\.wslconfig), and what doescat /proc/sys/net/ipv4/ip_local_port_rangeshow?HTTP_PROXY/HTTPS_PROXY/NO_PROXYset inside WSL, or isautoProxyon?ss -ltnp | grep 49374), or was nothing listening?opencodejr commentedon Oct 28, 2026
Thanks for the detailed report! I think this is a duplicate of #50672, which covers the same problem. The managed service binds the hardcoded default port
49374with no fallback. When that port can't be bound, the client keeps retrying and shows only a generic wait or timeout, not the child's "port already in use …opencode service set port <port>" error. Your case is a Hyper-V/WSL reserved port range rather than a second client, but the cause and the fix you're asking for (a fallback port, or failing fast with the real error) are the same.Possible duplicates and closely related issues, ordered by likelihood:
Starting background server...when the Desktop app is installed and uses 49374 (same hang, and the Desktop/CLI port collision you mention)As a workaround, you can move the service off the blocked range with
opencode service set port <port>(picking a port outside the Hyper-V excluded ranges shown bynetsh interface ipv4 show excludedportrange protocol=tcp). Your points aboutservice set --helpand the Network docs not mentioningportare useful additions to #50672.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.