Repository navigation
Description
Description
On Windows, the OpenCode Desktop sidecar process dies silently at random intervals. The only symptom is [global-sdk] event stream error [object Object] in renderer.log, followed by a cascade of TypeError: Failed to fetch errors. The user must close and restart the Desktop app entirely to recover.
Critically:
server.logshows nothing — the sidecar process terminates without logging its own deathmain.logshows nothing — no "sidecar exited", "connection lost", or error entry is recorded- Only
renderer.logcaptures the symptom
Environment
- OS: Windows
- OpenCode Desktop: v1.15.13 (also occurred on v1.15.12)
- Node: bundled with Desktop
Difference from #29599
Issue #29599 reports ACCESS_VIOLATION crashes. In our case there is no ACCESS_VIOLATION — this is a silent death/hang. The sidecar process simply stops responding, and its death is not logged anywhere.
Attempted workarounds (all unsuccessful)
server.portinopencode.json— Desktop completely ignores this setting. It chooses the port before spawning the sidecar and before reading config. Confirmed inmain.log: the port is logged before any config is loaded.OPENCODE_PORTenvironment variable — sets the initial port but does NOT prevent the sidecar from dying. The disconnect still occurs.- No variable, no fixed port — the issue also occurs without any of the above. Sessions with random ports (e.g. 57360, 24969, 5929) also experienced the same silent death.
None of these workarounds prevent the issue. The problem is the sidecar dying, not the port configuration.
Timeline: 12 disconnections in 6 days
| # | Session start | Event stream error | Uptime |
|---|---|---|---|
| 1 | 28 May 17:21 | 29 May 02:11 | ~9h |
| 2 | (continuation) | 30 May 11:19 | ~33h |
| 3 | (continuation) | 30 May 23:51 | ~12.5h |
| 4 | (continuation) | 31 May 22:07 | ~22h |
| 5 | (continuation) | 01 Jun 18:53 | ~21h |
| 6 | 02 Jun 08:49 | 02 Jun 09:35 | ~46min |
| 7 | 02 Jun 10:12 | 02 Jun 18:00 | ~8h |
| 8 | 02 Jun 18:17 | 02 Jun 18:27 | ~10min |
| 9 | 03 Jun 05:49 | 03 Jun 08:55 | ~3h |
| 10 | 03 Jun 09:01 | 03 Jun 10:23 | ~1.3h |
| 11 | 03 Jun 10:25 | 03 Jun 10:32 | ~6min |
| 12 | 03 Jun 10:33 | (current session) | ongoing |
Uptime varies wildly (6 minutes to 33 hours). No fixed timeout pattern.
Log excerpts
renderer.log (only log that captures the issue):
[2026-06-03 10:32:23.367] [error] [global-sdk] event stream error [object Object]
[2026-06-03 10:33:29.358] [error] Uncaught (in promise) TypeError: Failed to fetch
server.log (empty — sidecar dies without logging):
[2026-06-03 10:25:49.565] [info] server ready { url: 'http://127.0.0.1:46456' }
(nothing after this — process terminated silently)
main.log (no record of disconnection):
[2026-06-03 10:25:49.565] [info] server ready { url: 'http://127.0.0.1:46456' }
(nothing after this)
Additional context
- Sessions before
OPENCODE_PORTwas set (random ports: 57360, 24969, 5929) also experienced the same issue - The
server.portconfig key inopencode.jsonis completely ignored by the Desktop app — it selects the port before spawning the sidecar, before reading any config - Related: Sidecar crashes repeatedly on Windows (exit code 1 + ACCESS_VIOLATION) - v1.15.3/v1.15.4 #29599 (ACCESS_VIOLATION crashes on Windows), Desktop app (Windows, v1.15.12): sidecar server exits on startup — "Unexpected server error", models/providers missing #29932 (sidecar exits on startup)
Activity
github-actions commentedon Jun 3, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is distinct from these (e.g. the sidecar process actually exits vs. hangs alive), it may be worth cross-referencing them for context.
daysus commentedon Jun 24, 2026
Testing update
Confirmed the SSE heartbeat fix works on OpenCode Desktop v1.17.9 (Windows, Electron build).
Separately discovered a pre-existing native crash in the Electron utility worker thread (unrelated to SSE). The desktop auto-recovers from it.
PR: #33646
daysus commentedon Jun 24, 2026
Final update - testing complete
SSE heartbeat fix confirmed working on Windows Electron Desktop v1.17.9 via direct asar patching.
Separate issue discovered: The Electron desktop has a pre-existing "zombie server" bug where the worker thread becomes unresponsive to API calls after 4-8 min while still returning HTTP 200 on health checks. This is unrelated to the SSE heartbeat and affects the stock v1.17.9 desktop. The standalone CLI binary does not exhibit this.
PR with fix: #33646
github-actions commentedon Aug 24, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.