Desktop v1.18.11 freezes completely when streaming from opencode-go provider

Summary

OpenCode Desktop (Windows) freezes completely (entire UI unresponsive, settings dialog won't open, all requests hang, no logs are written) whenever a streaming request is made to any model through the opencode-go provider. The process must be killed and restarted. This reproduces even with a single session, single model, and no proxy/VPN active — so it is not a concurrency issue, not a network/proxy issue, and not a server-side issue (direct API calls to the same endpoint succeed).

Environment

• OS: Windows 10
• App: OpenCode Desktop v1.18.11 (installed dir updated 2026-08-01 19:26)
• Provider that triggers the freeze: opencode-go (baseURL https://opencode.ai/zen/go/v1) — e.g. deepseek-v4-pro, kimi-k3, qwen3.7-plus
• Provider that works fine: opencode (Zen free tier, e.g. big-pickle) — runs for hours without issue

Timeline of evidence (from %USERPROFILE%\.local\share\opencode\log\opencode.log)

• 2026-07-25 ~ 07-30: Only opencode provider (big-pickle) used. Sessions run 60–400 minutes. No freezes.
• 2026-07-31 18:02 (local): First-ever opencode-go stream request (deepseek-v4-flash). Short-lived processes begin.
• 2026-08-01 19:26: Desktop updated (to v1.18.11).
• 2026-08-03 morning: Repeated freezes, all of them matching the same signature:

The last repro is the most telling: one single go-model streaming request, no VPN, no other sessions — froze the whole app in ~74 seconds.

Signature of the freeze

• The last log line is always the go-model stream start (or loop step=N) — never an error, crash, or abort.
• The Electron process becomes completely unresponsive (UI frozen, settings button dead). Nothing can be written to the log afterwards — evidence of main-thread / process-wide blocking, not a normal crash.
• It does not recover on its own; requires killing the app.

What has been ruled out

1. Server-side / API: Direct HTTPS calls to https://opencode.ai/zen/go/v1 with the same key return HTTP 200; /models lists all 24 models (1394ms); real chat with kimi-k3 returns 200 (3075ms); streaming deepseek-v4-pro delivers 125 SSE chunks ending with data: [DONE] (1739ms). The SSE format matches what opencode (big-pickle) uses.
2. Proxy / VPN: Freeze also occurs with system proxy disabled (ProxyEnable=0, port 17891 not listening). The go API is directly reachable from China without any proxy.
3. Concurrency / multiple sessions: Reproduced with a single session making a single streaming request.
4. API key / subscription: Same key works fine via raw HTTP.
5. models.dev fetch timeout: Exists (15s timeout domestically) but also occurred on days with zero freezes — noise, not the cause.

Repro steps

1. Use OpenCode Desktop v1.18.11 on Windows.
2. Configure opencode-go provider (models like deepseek-v4-pro, kimi-k3).
3. Start any session with a go model and send a message that triggers a streamed response.
4. Within ~1–2 minutes the entire app freezes (UI unresponsive, no further log lines, no error in log).

Expected behavior

Streaming responses from opencode-go models should not freeze the application — the same streaming path works for the opencode provider.

Notes

• Log location: %USERPROFILE%\.local\share\opencode\log\opencode.log
• Happy to attach the relevant log excerpts (they're large; let me know the best way to share) or run a debug build / enable debug logging if that helps.
• Rolling back to v1.18.10 is our planned next step to confirm the regression; happy to report results.