desktop: background service spawn fails "port in use" on Windows/WSL2 mirrored networking — app stuck at logo, error not logged #55907

Summary

On Windows with WSL2 in mirrored networking mode, the desktop app's background service (opencode-cli.exe serve --service) repeatedly fails to start: multiple concurrent spawns race for the fixed managed service port, failed spawns are surfaced as a fatal Desktop IPC handler failed error, and the app gets stuck at the logo. The underlying bind error is never logged to main.log.

Environment

• Desktop app: 2.0.29 and 2.0.30 (both affected)
• Bundled CLI: 2.0.29 / 2.0.30 (opencode-cli.exe serve --service)
• OS: Windows 11 Home x64 (build 10.0.26300)
• WSL: 3.0.3.0, distro Ubuntu (running), kernel 6.18.54.1-microsoft-standard-WSL2
• .wslconfig: networkingMode=Mirrored + [experimental] hostAddressLoopback=true
• A WSL-side shared service (opencode serve --service, v2.0.30) runs inside the distro on 127.0.0.1:49374; mirrored loopback (hostAddressLoopback=true) exposes it to Windows at 127.0.0.1:49374

Reproduction

1. Install the desktop app on a machine where the WSL distro runs the opencode shared service (or where the managed service port is otherwise occupied on Windows loopback)
2. Launch the desktop app (cold start, or restart while the previous sidecar is still shutting down)
3. main.log shows v2 CLI background service starting { reason: 'missing' } — repeated, with no service ready
4. Windows-side service log shows repeated errors:
   Managed service port <N> on 127.0.0.1 is already in use by another process. Configure another port with \opencode service set port ` ...`
5. App stuck at logo / error dialog: Desktop IPC handler failed → Server process exited with code 1

Observed on both default ports:

• 2.0.29 (49374): collides with the WSL-side service exposed on Windows loopback via mirrored networking
• 2.0.30 (45278): the app's own concurrent spawns race for the port — at least one instance binds and serves (visible in the log: /api/event requests served), while later duplicate spawns fail with 45278 already in use; Service.ensure surfaces the failed duplicate as fatal instead of adopting the serving instance

Expected Behavior

• Spawn attempts are serialized; a running compatible instance is adopted (or waited on) instead of racing
• If a spawn fails to bind, the underlying error is logged to main.log and surfaced gracefully (window loads, connection retried) instead of a silent abort / stuck logo

Actual Behavior

• Service.ensure treats a failed spawn as fatal; the underlying bind error is never written to main.log
• App stuck at logo; error dialog: UnknownError: An error occurred in Effect.tryPromise → Server process exited with code 1

Additional Context

• Workaround: an explicit free port in %USERPROFILE%\.config\opencode\service.json ({"port": <free>}) lets the service start
• Related issues: Desktop: silent abort before window creation when sidecar utilityProcess.fork fails #49562 (silent abort without logging — same pattern), opencode2 became stuck starting its managed background server #41696, [v2 Windows] opencode2 hangs at "Starting background server..." after reinstall #41746
• Note: a fixed well-known service port also collides with WSL-side bindings under mirrored networking (hostAddressLoopback=true), so a fixed port on Windows collides by design in this environment. Suggest considering an ephemeral service port + registration-file discovery, or excluding ports held by mirrored WSL bindings
• Suggestion: log the failed spawn's underlying error in main.log — currently the one useful piece of information is the only thing never written anywhere (same as described in Desktop: silent abort before window creation when sidecar utilityProcess.fork fails #49562)