[Bug]: Windows Desktop 1.18.30 renderer blocked by local proxy (AdGuard) - sidecar returns 500 Request Blocked, UI shows Could not reach Local Server

Description

After AdGuard for Windows updated itself and restarted the PC (planned "Application: Installation" restart at 09:47 local, confirmed in Windows System Event Log, Event ID 1074, initiator Adguard.exe), OpenCode Desktop on Windows can no longer connect its renderer to the bundled local sidecar server. The UI shows "Could not reach Local Server / Retrying automatically...".

The failing component is the renderer -> sidecar loopback connection. All requests from the renderer origin oc://renderer are blocked at the CORS preflight stage because the preflight response status is not OK. Probing the sidecar port directly returns HTTP/1.1 500 Request Blocked for both OPTIONS preflight and plain GET - a response produced by a local interception layer in the loopback path, not by opencode's server logic.

Requesting coordination so that AdGuard can mark the OpenCode Desktop Electron UI and its loopback sidecar traffic as safe/excluded, or so OpenCode Desktop can detect and surface this interference with user guidance (e.g. add loopback exclusions for OpenCode processes).

Environment

• OS: Windows 11, x64
• OpenCode Desktop: 1.18.30 (also reproduced on 1.18.18)
• Local proxy: AdGuard for Windows (filtering stopped during latest test; issue persists)
• Desktop UI state: fresh (opencode.global.dat removed, onboarding re-ran)
• CLI opencode serve on the same machine works normally on its own port

Steps to reproduce

1. Install AdGuard for Windows, let it update and restart.
2. Launch OpenCode Desktop 1.18.30 with fresh UI state.
3. Observe "Could not reach Local Server", retrying indefinitely.

Evidence

renderer.log (every launch, immediately after server ready):

Access to fetch at 'http://127.0.0.1:63257/global/health' from origin 'oc://renderer' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.
Access to fetch at 'http://127.0.0.1:63257/api/health' from origin 'oc://renderer' has been blocked by CORS policy: ...
Access to fetch at 'http://127.0.0.1:63257/api/event' from origin 'oc://renderer' has been blocked by CORS policy: ...
[global-sdk] event stream failed [object Object]

main.log:

spawning sidecar { url: 'http://127.0.0.1:63257' }
sidecar health check failed TimeoutError
awaiting server ready
server ready { url: 'http://127.0.0.1:63257' }

Direct probe of the live sidecar port (curl, no auth):

> OPTIONS /global/health  (Origin: oc://renderer, Access-Control-Request-Method: GET)
HTTP/1.1 500 Request Blocked
Connection: close
Content-Type: text/plain
Content-Length: 0
Access-Control-Allow-Origin: oc://renderer
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: authorization,content-type
Access-Control-Allow-Methods: GET

> GET /global/health
HTTP/1.1 500 Request Blocked
Connection: close

The 500 Request Blocked response with CORS allow headers present indicates a local interception/proxy layer in the loopback path rather than an opencode server error.

What we tried

• Full upgrade 1.18.18 -> 1.18.30 (updater reported up-to-date)
• Reset desktop UI state (removed opencode.global.dat; onboarding re-ran)
• Disabled AdGuard filtering; issue persists
• Verified CLI opencode serve is unaffected

Expected behavior

Renderer should reach the bundled sidecar on 127.0.0.1 regardless of local filtering software, or the app should detect and surface the interference with guidance (e.g. add loopback/exclusion for OpenCode processes in the user's proxy/firewall).

Related

• #30597 sidecar dies silently on Windows (event stream error)
• #41986 [global-sdk] event stream failed race condition
• #33646 heartbeat/backoff proposal (closed, unmerged)