Repository navigation
Desktop WSL sidecar fails with ServeError when networkingMode=mirrored #37718
Description
Description
OpenCode Desktop's managed WSL server consistently fails to start when WSL2 uses mirrored networking. The Desktop recognizes the distro and native Linux binary correctly, but the sidecar exits before health checking with only:
Error: Unexpected error
ServeError
This appears to be a port-allocation handoff issue in packages/desktop/src/main/wsl/sidecar.ts: allocatePort() reserves an ephemeral port on Windows, closes it, and then asks WSL to bind 0.0.0.0 on the same port. With networkingMode=mirrored, Windows and WSL share the port space, and the immediate WSL bind fails.
I reproduced the same allocation sequence independently 8 times; all 8 attempts failed with the identical Unexpected error / ServeError. Starting the same WSL binary directly on a known free fixed port succeeds.
Plugins
None in the WSL config.
OpenCode version
Desktop and WSL binary: 1.18.3
Steps to reproduce
-
Configure
%USERPROFILE%\.wslconfig:[experimental] networkingMode=mirrored dnsTunneling=true autoProxy=true
-
Run
wsl --shutdown, then start OpenCode Desktop. -
Add an installed WSL2 distro as a managed WSL server.
-
Observe that the server repeatedly fails before becoming healthy.
Desktop log:
wsl sidecar starting { id: 'wsl:Ubuntu-24.04', distro: 'Ubuntu-24.04' }
wsl sidecar { distro: 'Ubuntu-24.04', stream: 'stderr', text: 'Error: Unexpected error' }
wsl sidecar { distro: 'Ubuntu-24.04', stream: 'stderr', text: 'ServeError' }
wsl sidecar failed to start {
message: 'WSL server exited before becoming healthy (code=1 signal=null)'
}
Control test that succeeds:
~/.opencode/bin/opencode serve --hostname 0.0.0.0 --port 4096Expected: the managed WSL sidecar starts while mirrored networking remains enabled.
A possible fix would be to allocate the port from inside WSL, let opencode serve --port 0 report its selected port, or retry when the cross-environment port handoff fails.
Operating System
Windows 11 25H2 build 26200.8875; WSL 2.9.3.0; Ubuntu-24.04 distro.
Terminal
OpenCode Desktop managed WSL server (reproduced independently from PowerShell).
Activity
dzianisv commentedon Jul 24, 2026
Root cause of the opaque
Error: Unexpected error / ServeErroroutput here is tracked in #38738 — Effect'sServeErroris aData.TaggedErrorwith an emptymessage, and opencode'serrorMessage()never reads.cause, so the reallistenerrno is dropped.Relevant to your mirrored-networking diagnosis: under Bun,
node:httplisten()reports every failure asEADDRINUSE(#38739) — verified against Node, which correctly returnsEADDRNOTAVAIL/EACCESfor the same binds. So the WSL sidecar failure may not be a port conflict at all; the errno cannot distinguish it. With #38738 applied the sidecar would print the actual cause instead ofServeError, which should settle it either way.fix(serve): surface the real bind error instead of "Unexpected error …
Rokurolize commentedon Aug 14, 2026
Additional observation, now with the command-line client (opencode2, v2 preview) in the same environment (Windows 11, WSL2 with mirrored networking).
The v2 CLI background service fails to start for the same reason, and it shows a clean boundary:
netsh int ipv4 show dynamicport tcp), andnetstat -anoshowed nothing actually listening on the failing ports.So from inside WSL with mirrored networking, the whole Windows dynamic port range appears to be unavailable, even when no other process uses the port.
The v2 CLI hits this because its managed background server uses a fixed default port of 49374 (hard-coded as 0xc0de in service-config.ts of the shipped binary), which falls inside that range. On every launch the client spawned the server, the server failed to bind that port and exited, and the client silently started it again in a loop ("Starting background server..." with no visible error).
A workaround that works:
opencode2 service set port 48716(any free port below 49152). After that, the background server binds, its health endpoint reports healthy, and the client connects normally.Since the failing range starts exactly at 49152, keeping managed-service default ports below the Windows dynamic range (or letting the service pick a free port) would avoid this failure mode entirely.
github-actions commentedon Oct 14, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.