Description
Description
OpenCode Desktop crashes its local backend (sidecar) a few minutes after any turn
that actually edits files / does real tool work, on Windows. After the sidecar dies
the UI can no longer reach it, so every subsequent "Send" fails with
发送信息失败 / Failed to fetch until the app is fully restarted. The app does
not auto-restart the sidecar.
This was reproduced 6 times in a single session, with clean negative controls
(trivial text-only replies, read-only explore turns and long idle periods do not
crash). It is not caused by plugins (none installed), not by quota, not by
session/data size, not by memory pressure (sidecar stays ~170–330 MB and never
climbs), and it is not fixed by "snapshot": false.
The crash signature matches the existing reports in #26667 / #27755 / #45409 —
reproduced here on the latest version (1.18.27).
Plugins
No third-party plugins installed.
OpenCode version
OpenCode Desktop 1.18.27 (auto-update channel latest, says up-to-date).
Steps to reproduce
- Launch OpenCode Desktop on Windows (renderer is served over the
oc:// scheme;
the engine runs in a Node utility sidecar on http://127.0.0.1:<random port>).
- Open a session and ask the agent to do a real task that writes/edits files
(modify a source file, format several files, or spawn an explore subagent after
an edit) in a normal code project.
- Let the turn finish (log shows
exiting loop).
- Do nothing for ~2–5 minutes.
- Send the next message → it fails immediately with
发送信息失败 / Failed to fetch. Every further send fails too, until you fully close and relaunch the app.
Note: the crash also occurred once while an explore subagent was still streaming
steps (not only while idle after a finished turn). Trivial Q&A turns ("reply only",
no tool calls) completed fine and did not crash even after 6+ minutes of idle.
Screenshot and/or share link
Error toast text: 发送信息失败 followed by Failed to fetch (renderer
TypeError: Failed to fetch).
Operating System
Windows 10 Enterprise LTSC 2021 (build 10.0.19044). Also reported by others on
Windows 11 (#26667/#27755/#45409).
Evidence
1. The sidecar crashes with a Windows fail-fast code, then the renderer loses it.
<user AppData>\ai.opencode.desktop\logs\<run>\utility.log (identical on every crash):
sidecar exited { code: 3221226505 } # 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN / fail-fast)
child process gone {
details: {
type: 'Utility',
reason: 'crashed',
exitCode: -1073740791,
serviceName: 'node.mojom.NodeService',
name: 'opencode server'
}
}
...\logs\<run>\renderer.log right after the crash, when the user hits Send:
Uncaught (in promise) TypeError: Failed to fetch
No spawning sidecar line appears again in main.log after the crash → the app
does not restart it.
2. Timing correlation (same machine, same day):
| Turn type |
Ended (local) |
Sidecar crash |
Outcome |
| Real multi-step editing turn |
19:21:50 |
19:24:10 |
crashed (0xC0000409) |
| Real editing turn |
20:15:26 |
20:17:07 |
crashed (0xC0000409) |
| Real editing + explore subagent (snapshot off) |
21:50:10 |
21:53:28 |
crashed (0xC0000409) |
| Fresh session, read-only explore + 2 follow-ups |
20:35 / 20:42 |
– |
no crash, 15+ min stable |
| Trivial text-only reply in the SAME long session |
20:59:09 |
– |
no crash, 6+ min stable |
3. Engine log (<user data>/.local/share/opencode/log/opencode.log): each
crashing turn ends with a normal exiting loop, and no ERROR/stream error/
abort line is logged between the turn end and the crash. The crash itself produces
no engine log line (native process death).
4. Ruled out (with measurements):
- Memory: sidecar working set sampled every 2 s stayed ~170–330 MB across
crash/no-crash runs; no monotonic climb toward any heap limit.
- Session/data size: total database is 151 MB; the largest session's stored
content is only ~3.5 MB (1106 parts, biggest part 0.2 MB). Not a "bloated session".
"snapshot": false removes the tracking hash=... change-tracking lines but
the crash still reproduces → not the snapshot/git subsystem.- Plugins: none. Quota/upstream: no provider error logged before the crash;
it also crashed on turns with fully clean model streams. Provider/model:
opencode-go / mimo-v2.5 (the built-in "Console Go" gateway — flaky at other
times, but not the trigger here).
- NODE_OPTIONS (
--report-on-fatalerror) is rejected in packaged builds, and
Crashpad leaves no local minidump, so only the 0xC0000409 exit code is observable.
5. Suggested fix direction (consistent with #26667/#27755/#45409):
The sidecar is killed by an unhandled error in session/turn teardown after
tool-calling turns (session.processor family). Please make tool-turn completion
crash-safe on Windows (catch AbortError / wrap the per-turn Effect fiber with an
error boundary), and consider auto-restarting the sidecar when it dies so the UI
does not hard-lock into Failed to fetch.
Full diagnostics (memory time-series CSVs, engine/renderer/utility logs, a debug
launcher) are available if a maintainer wants them.
Plugins
No third-party plugins installed.
OpenCode version
1.18.27
Steps to reproduce
- Launch OpenCode Desktop on Windows (renderer is served over the
oc:// scheme;
the engine runs in a Node utility sidecar on http://127.0.0.1:<random port>).
- Open a session and ask the agent to do a real task that writes/edits files
(modify a source file, format several files, or spawn an explore subagent after
an edit) in a normal code project.
- Let the turn finish (log shows
exiting loop).
- Do nothing for ~2–5 minutes.
- Send the next message → it fails immediately with
发送信息失败 / Failed to fetch. Every further send fails too, until you fully close and relaunch the app.
Note: the crash also occurred once while an explore subagent was still streaming
steps (not only while idle after a finished turn). Trivial Q&A turns ("reply only",
no tool calls) completed fine and did not crash even after 6+ minutes of idle.
main.log
renderer.log
utility.log
Evidence
1. The sidecar crashes with a Windows fail-fast code, then the renderer loses it.
<user AppData>\ai.opencode.desktop\logs\<run>\utility.log (identical on every crash):
sidecar exited { code: 3221226505 } # 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN / fail-fast)
child process gone {
details: {
type: 'Utility',
reason: 'crashed',
exitCode: -1073740791,
serviceName: 'node.mojom.NodeService',
name: 'opencode server'
}
}
...\logs\<run>\renderer.log right after the crash, when the user hits Send:
Uncaught (in promise) TypeError: Failed to fetch
No spawning sidecar line appears again in main.log after the crash → the app
does not restart it.
2. Timing correlation (same machine, same day):
| Turn type |
Ended (local) |
Sidecar crash |
Outcome |
| Real multi-step editing turn |
19:21:50 |
19:24:10 |
crashed (0xC0000409) |
| Real editing turn |
20:15:26 |
20:17:07 |
crashed (0xC0000409) |
| Real editing + explore subagent (snapshot off) |
21:50:10 |
21:53:28 |
crashed (0xC0000409) |
| Fresh session, read-only explore + 2 follow-ups |
20:35 / 20:42 |
– |
no crash, 15+ min stable |
| Trivial text-only reply in the SAME long session |
20:59:09 |
– |
no crash, 6+ min stable |
3. Engine log (<user data>/.local/share/opencode/log/opencode.log): each
crashing turn ends with a normal exiting loop, and no ERROR/stream error/
abort line is logged between the turn end and the crash. The crash itself produces
no engine log line (native process death).
4. Ruled out (with measurements):
- Memory: sidecar working set sampled every 2 s stayed ~170–330 MB across
crash/no-crash runs; no monotonic climb toward any heap limit.
- Session/data size: total database is 151 MB; the largest session's stored
content is only ~3.5 MB (1106 parts, biggest part 0.2 MB). Not a "bloated session".
"snapshot": false removes the tracking hash=... change-tracking lines but
the crash still reproduces → not the snapshot/git subsystem.- Plugins: none. Quota/upstream: no provider error logged before the crash;
it also crashed on turns with fully clean model streams. Provider/model:
opencode-go / mimo-v2.5 (the built-in "Console Go" gateway — flaky at other
times, but not the trigger here).
- NODE_OPTIONS (
--report-on-fatalerror) is rejected in packaged builds, and
Crashpad leaves no local minidump, so only the 0xC0000409 exit code is observable.
5. Suggested fix direction (consistent with #26667/#27755/#45409):
The sidecar is killed by an unhandled error in session/turn teardown after
tool-calling turns (session.processor family). Please make tool-turn completion
crash-safe on Windows (catch AbortError / wrap the per-turn Effect fiber with an
error boundary), and consider auto-restarting the sidecar when it dies so the UI
does not hard-lock into Failed to fetch.
Full diagnostics (memory time-series CSVs, engine/renderer/utility logs, a debug
launcher) are available if a maintainer wants them.
Screenshot and/or share link
Error toast text: 发送信息失败 followed by Failed to fetch (renderer
TypeError: Failed to fetch).
Operating System
Windows 10 Enterprise LTSC 2021 (build 10.0.19044). Also reported by others on Windows 11 (#26667/#27755/#45409).
Terminal
No response
Description
Description
OpenCode Desktop crashes its local backend (sidecar) a few minutes after any turn
that actually edits files / does real tool work, on Windows. After the sidecar dies
the UI can no longer reach it, so every subsequent "Send" fails with
发送信息失败/Failed to fetchuntil the app is fully restarted. The app doesnot auto-restart the sidecar.
This was reproduced 6 times in a single session, with clean negative controls
(trivial text-only replies, read-only explore turns and long idle periods do not
crash). It is not caused by plugins (none installed), not by quota, not by
session/data size, not by memory pressure (sidecar stays ~170–330 MB and never
climbs), and it is not fixed by
"snapshot": false.The crash signature matches the existing reports in #26667 / #27755 / #45409 —
reproduced here on the latest version (1.18.27).
Plugins
No third-party plugins installed.
OpenCode version
OpenCode Desktop 1.18.27 (auto-update channel
latest, says up-to-date).Steps to reproduce
oc://scheme;the engine runs in a Node utility sidecar on
http://127.0.0.1:<random port>).(modify a source file, format several files, or spawn an explore subagent after
an edit) in a normal code project.
exiting loop).发送信息失败/Failed to fetch. Every further send fails too, until you fully close and relaunch the app.Screenshot and/or share link
Error toast text:
发送信息失败followed byFailed to fetch(rendererTypeError: Failed to fetch).Operating System
Windows 10 Enterprise LTSC 2021 (build 10.0.19044). Also reported by others on
Windows 11 (#26667/#27755/#45409).
Evidence
1. The sidecar crashes with a Windows fail-fast code, then the renderer loses it.
<user AppData>\ai.opencode.desktop\logs\<run>\utility.log(identical on every crash):...\logs\<run>\renderer.logright after the crash, when the user hits Send:No
spawning sidecarline appears again inmain.logafter the crash → the appdoes not restart it.
2. Timing correlation (same machine, same day):
3. Engine log (
<user data>/.local/share/opencode/log/opencode.log): eachcrashing turn ends with a normal
exiting loop, and noERROR/stream error/abort line is logged between the turn end and the crash. The crash itself produces
no engine log line (native process death).
4. Ruled out (with measurements):
crash/no-crash runs; no monotonic climb toward any heap limit.
content is only ~3.5 MB (1106 parts, biggest part 0.2 MB). Not a "bloated session".
"snapshot": falseremoves thetracking hash=...change-tracking lines butthe crash still reproduces → not the snapshot/git subsystem.
it also crashed on turns with fully clean model streams. Provider/model:
opencode-go/mimo-v2.5(the built-in "Console Go" gateway — flaky at othertimes, but not the trigger here).
--report-on-fatalerror) is rejected in packaged builds, andCrashpad leaves no local minidump, so only the 0xC0000409 exit code is observable.
5. Suggested fix direction (consistent with #26667/#27755/#45409):
The sidecar is killed by an unhandled error in session/turn teardown after
tool-calling turns (
session.processorfamily). Please make tool-turn completioncrash-safe on Windows (catch AbortError / wrap the per-turn Effect fiber with an
error boundary), and consider auto-restarting the sidecar when it dies so the UI
does not hard-lock into
Failed to fetch.Full diagnostics (memory time-series CSVs, engine/renderer/utility logs, a debug
launcher) are available if a maintainer wants them.
Plugins
No third-party plugins installed.
OpenCode version
1.18.27
Steps to reproduce
oc://scheme;the engine runs in a Node utility sidecar on
http://127.0.0.1:<random port>).(modify a source file, format several files, or spawn an explore subagent after
an edit) in a normal code project.
exiting loop).发送信息失败/Failed to fetch. Every further send fails too, until you fully close and relaunch the app.main.log
renderer.log
utility.log
Evidence
1. The sidecar crashes with a Windows fail-fast code, then the renderer loses it.
<user AppData>\ai.opencode.desktop\logs\<run>\utility.log(identical on every crash):...\logs\<run>\renderer.logright after the crash, when the user hits Send:No
spawning sidecarline appears again inmain.logafter the crash → the appdoes not restart it.
2. Timing correlation (same machine, same day):
3. Engine log (
<user data>/.local/share/opencode/log/opencode.log): eachcrashing turn ends with a normal
exiting loop, and noERROR/stream error/abort line is logged between the turn end and the crash. The crash itself produces
no engine log line (native process death).
4. Ruled out (with measurements):
crash/no-crash runs; no monotonic climb toward any heap limit.
content is only ~3.5 MB (1106 parts, biggest part 0.2 MB). Not a "bloated session".
"snapshot": falseremoves thetracking hash=...change-tracking lines butthe crash still reproduces → not the snapshot/git subsystem.
it also crashed on turns with fully clean model streams. Provider/model:
opencode-go/mimo-v2.5(the built-in "Console Go" gateway — flaky at othertimes, but not the trigger here).
--report-on-fatalerror) is rejected in packaged builds, andCrashpad leaves no local minidump, so only the 0xC0000409 exit code is observable.
5. Suggested fix direction (consistent with #26667/#27755/#45409):
The sidecar is killed by an unhandled error in session/turn teardown after
tool-calling turns (
session.processorfamily). Please make tool-turn completioncrash-safe on Windows (catch AbortError / wrap the per-turn Effect fiber with an
error boundary), and consider auto-restarting the sidecar when it dies so the UI
does not hard-lock into
Failed to fetch.Full diagnostics (memory time-series CSVs, engine/renderer/utility logs, a debug
launcher) are available if a maintainer wants them.
Screenshot and/or share link
Error toast text:
发送信息失败followed byFailed to fetch(rendererTypeError: Failed to fetch).Operating System
Windows 10 Enterprise LTSC 2021 (build 10.0.19044). Also reported by others on Windows 11 (#26667/#27755/#45409).
Terminal
No response