cli: service configured with hostname 0.0.0.0 is unreachable when an HTTP proxy is set

Description

opencode service set hostname 0.0.0.0 (the remote-access setup opencode pair recommends) makes the local CLI unable to reach the service when an HTTP proxy is set.

The server writes its bind address to the registration file:

// ~/.local/state/opencode/service.json
{"url":"http://0.0.0.0:49374","pid":64411,"version":"2.0.8"}

The client probes that url verbatim (packages/client/src/effect/service.ts: fetch(new URL("/api/status", info.url))) and reuses it as baseUrl, so with http_proxy set and 0.0.0.0 not in no_proxy the proxy answers 502 and the service looks unhealthy.

Desktop already rewrites the wildcard to loopback (packages/desktop/src/main/service/background-service.ts:53, #43171). The CLI does not.

Plugins

Local: ollama-peak-pricing, rtk.

OpenCode version

2.0.8

Steps to reproduce

1. opencode service set hostname 0.0.0.0 && opencode service restart
2. export http_proxy=http://127.0.0.1:7897
3. opencode . fails. no_proxy=* opencode . works.

Without the client:

curl -x $http_proxy http://0.0.0.0:49374/api/status    # 502
curl -x $http_proxy http://127.0.0.1:49374/api/status  # 401

Expected Behavior

Local client connects over loopback, as the desktop client does. Remote clients keep using the LAN URLs from opencode pair.

Actual Behavior

Client talks to http://0.0.0.0:<port>, which a proxy cannot dial.

Operating System

Windows 11 + WSL2 (Ubuntu), mirrored networking

Terminal

Windows Terminal, TERM=xterm-256color

Start in packages/client/src/effect/service.ts, where the service URL is read, probed, and reused as baseUrl, then compare the wildcard handling in packages/desktop/src/main/service/background-service.ts:53. Reproduce with http_proxy set and a service bound to 0.0.0.0; done means the local CLI uses loopback while remote clients retain their LAN URLs, and the status request succeeds without no_proxy.