desktop: no live updates for in-progress sessions when connected to a WSL server

Summary

When OpenCode Desktop is connected to a managed WSL server, a session that is being driven by the WSL CLI/TUI does not update in real time in Desktop. Desktop can list and open the same session (both servers share one SQLite DB), but never receives live events for it.

Root cause: Desktop's WSL integration spawns its own opencode serve sidecar instead of attaching to the per-user shared background service that the WSL CLI/TUI uses. Live session state is process-local (in-memory event stream), so two server processes over one database cannot stream to each other. On Windows, Desktop attaches to the same shared background service as the Windows CLI, which is why Windows stays in sync.

Environment

• opencode version: 2.0.3 (Desktop and WSL CLI)
• OS (Desktop): Windows 11, Windows_NT 10.0.26200 (win32 x64)
• OS (server): Debian GNU/Linux 13 (trixie), WSL2, kernel 6.18.33.2-microsoft-standard-WSL2
• Terminal: OpenCode Desktop (Electron); WSL used from an interactive shell
• Shell: Windows C:\WINDOWS\system32\cmd.exe; WSL /bin/bash
• Install/channel: latest (Windows Desktop 2.0.3; WSL CLI at ~/.opencode/bin/opencode)
• Active plugins: WSL global config has opencode-workspace-scope@0.2.0-beta.1; no plugins in Windows global config

Reproduction

1. In WSL (Debian), install opencode 2.0.3 and confirm the shared background service is running: opencode service status (example: http://127.0.0.1:4096).
2. In OpenCode Desktop on Windows, add the Debian distro as a managed WSL server and make it the default server.
3. In WSL, open the TUI (opencode) in a project and send a prompt so a turn is actively streaming.
4. In Desktop, open that same session while the turn is still running.
5. Observe that Desktop shows the session and its history, but the in-progress turn does not stream/update.

Expected Behavior

Desktop and the WSL CLI/TUI share the same server, so an in-progress session updates live in both clients — the same way Windows Desktop + Windows CLI behave.

Actual Behavior

No live updates in Desktop for a session driven by the WSL CLI/TUI. Both clients see the same session, but only through the shared database, not through a shared event stream. Content appears only after the turn completes and Desktop re-reads (switching sessions / reloading).

Additional Context

Desktop and the WSL CLI use two different servers in the same distro:

$ wsl -d Debian -- ps -eo pid,ppid,args | grep -i opencode
17525 17524  /home/gnh/.opencode/bin/opencode --log-level warn serve --hostname 0.0.0.0 --port 58005   # Desktop WSL sidecar
23902  1162  /home/gnh/.opencode/bin/opencode serve --service                                         # shared background service (CLI/TUI)
24775 24192  opencode                                                                                  # TUI

WSL shared service registration:

$ cat ~/.local/state/opencode/service.json
{"id":"...","version":"2.0.3","url":"http://127.0.0.1:4096","pid":23902,"password":"<redacted>"}

Desktop log (%APPDATA%\ai.opencode.desktop\logs\<timestamp>\main.log):

v2 CLI background service ready { version: '2.0.3', url: 'http://127.0.0.1:49374', ... }   # Windows-local shared service
wsl sidecar starting { id: 'wsl:Debian', distro: 'Debian' }
wsl sidecar ready { id: 'wsl:Debian', distro: 'Debian', url: 'http://127.0.0.1:58005' }     # WSL sidecar

For comparison, on Windows the CLI and Desktop share one service, which is why they stay in sync:

$ opencode service status
http://127.0.0.1:49374

Both WSL servers point at the same database (~/.local/share/opencode/opencode.db), which is why the session is visible in both clients; but opencode serve --service (shared) and the Desktop sidecar are distinct processes with distinct in-memory event buses, so events cannot cross.

Notes:

• PR #40743 removed the superseded local sidecar so Desktop local startup uses startBackgroundCli (shared service), but the WSL path still spawns a separate sidecar (packages/desktop/src/main/wsl/sidecar.ts).
• Suggest: either have the managed WSL server attach to the user's shared background service in that distro, or make it explicit in the UI that the WSL server is a separate instance.

Related: #23407, #29766, #17451

Workarounds:

• Use the web UI served by the WSL shared service (opencode pair in WSL) instead of Desktop.
• Keep the CLI and Desktop on the same side (both Windows).
• Point Desktop at the WSL shared service as a custom server (requires the service password).