[Desktop] sidecar process crashes with OOM - JavaScript heap out of memory #47553

Activity

1. github-actions

   assigned

   Hona

   on Sep 6, 2026
2. github-actions commented on Sep 6, 2026

   

   github-actionsBot

   on Sep 6, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • Desktop sidecar repeatedly crashes with V8 out-of-memory, causing local server red and Failed to fetch #41964: Desktop sidecar repeatedly crashes with V8 out-of-memory — same symptom of unbounded memory growth crashing the sidecar on desktop
   • Server main process OOMs at ~3.9 GB heap (feedback-monitor.js MODULE_TYPELESS_PACKAGE_JSON), sidecar exits clean (code 0), renderer bootstrap fails — v1.18.14 win32 #44856: Server main process OOMs at ~3.9 GB heap, sidecar exits clean (code 0) — very similar OOM pattern with sidecar exit code 0 and restart loop
   • OOM crash on startup: Event table snapshot + session revert data grow to 1.4GB, sidecar V8 process runs out of memory #38362: OOM crash with sidecar V8 process running out of memory — same root area (event table / memory leak causing V8 OOM in sidecar)

   If your issue is the same as one of these, please consider adding a comment there instead so discussion stays consolidated.
3. iuridiniz commented on Sep 25, 2026

   

   iuridiniz

   on Sep 25, 2026

   More actions

   I can reproduce this on macOS Apple Silicon with OpenCode Desktop 1.18.32 (installed via Homebrew), and the local logs provide a clear failure chain.

   Observed locally:

   • 2026-09-24 19:23:03: sidecar V8 OOM at 3,768.2 MB heap, then Reached heap limit ... JavaScript heap out of memory; Desktop reported sidecar exited { code: 5 }.
   • 2026-09-24 22:32:21: sidecar V8 OOM at 3,725.5 MB heap, then the same exit code 5.
   • 2026-09-25 14:41:17: sidecar V8 OOM at 3,472 MB heap, followed immediately by sidecar exited { code: 5 }.
   • At the same timestamp as the last crash, the renderer repeatedly logged TypeError: Failed to fetch while loading session messages and then reported a fatal renderer error.

   The app starts normally and logs server ready before the failure, so this is not a startup/update problem. The GUI becomes disconnected because the embedded sidecar dies after exhausting the V8 heap. The CLI remains usable.

   This reproduces the issue on macOS and on a newer Desktop release than the original report. The logs also show repeated ResizeObserver loop completed with undelivered notifications, but the direct cause of the disconnect is the sidecar OOM.

   I can provide the relevant redacted log bundle if needed.
4. iuridiniz commented on Sep 25, 2026

   

   iuridiniz

   on Sep 25, 2026

   More actions

   Additional evidence from my local OpenCode Desktop data directory (macOS Apple Silicon, Desktop 1.18.32):

   • opencode.db is currently about 11 GB.
   • SQLite dbstat reports about 11.2 GB for the event table.
   • message.part.updated.1 accounts for 394,430 rows and about 10.46 GB of serialized event payloads (average ~26 KB, maximum ~1.35 MB).
   • message.updated.1 adds about 177 MB.
   • The largest single session aggregate contains about 190,172 events totaling about 5.54 GB.

   This makes the unbounded event/message-part history a strong candidate for the sidecar OOM observed above. The sidecar repeatedly reaches roughly 3.5–3.8 GB V8 heap and exits with code 5; the renderer then reports TypeError: Failed to fetch. I have not deleted or modified the database.

   This also appears consistent with the failure mode described in #35107 and #43551, but the measurements above are from my affected Desktop installation and version 1.18.32.
5. iuridiniz commented on Sep 25, 2026

   

   iuridiniz

   on Sep 25, 2026

   Last edited by iuridiniz

   More actions

   Follow-up after deleting one session only (the largest session) through the Desktop UI and running SQLite VACUUM:

   Before cleanup:

   • opencode.db: about 11 GB
   • event table: about 11.2 GB
   • message.part.updated.1: 394,430 rows / about 10.46 GB
   • The one largest session: about 190,172 events / about 5.54 GB

   After deleting that single long-running session and vacuuming:

   • opencode.db: 278 MB
   • event table: about 241 MB
   • message.part.updated.1: 27,635 rows / about 105 MB
   • Total events: 39,049
   • SQLite integrity check: ok

   Deleting only one session reclaimed almost the entire 11 GB. This strongly suggests that long-running sessions are closely related to the sidecar OOM in my case. The underlying issue still appears to be unbounded accumulation of streaming message.part.updated.1 events during long sessions; the remaining 27k rows show that this accumulation continues.
6. Atomheart-Father commented on Oct 8, 2026

   

   Atomheart-Father

   on Oct 8, 2026

   More actions

   Reproduced on macOS / Apple Silicon with OpenCode Desktop 1.18.35.

   I am seeing repeated sidecar/server crashes during normal active use. In the latest exported debug bundle, the crash sequence is consistently:

   OOM error in V8: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
   

   followed by:

   sidecar exited { code: 5 }
   

   and then the renderer begins failing with:

   TypeError: Failed to fetch
   

   This is not a one-off crash. I have 5 separate Crashpad .dmp reports across Oct 7–8, with repeated OOM crashes after restarting the Desktop app.

   Environment / observations:

   • macOS, Apple Silicon
   • OpenCode Desktop 1.18.35
   • Failure sequence: sidecar memory growth → V8 OOM → sidecar exits → renderer loses connection to the local server
   • Happens during normal active use, not only at startup
   • Workload includes long-running, tool-heavy sessions and multiple projects
   • I use Harness Memory. I do not know whether it is causal, but I can test with it disabled if useful.

   The exported debug bundle contains the related logs and Crashpad dumps. I can provide the full bundle / .dmp files if useful.

   This is currently very disruptive because once the sidecar dies, active Desktop sessions become unusable until the application is restarted.
7. Atomheart-Father commented on Oct 8, 2026

   

   Atomheart-Father

   on Oct 8, 2026

   More actions

   I was able to reproduce this again on macOS / Apple Silicon with OpenCode Desktop 1.18.35, and found an additional failure mode that may explain why the crash sometimes appears to be triggered by a UI action.

   In this reproduction:

   1. A long-running session stopped making progress and appeared to be stuck.
   2. The Desktop UI itself remained visible and interactive.
   3. I later clicked "View reasoning summary".
   4. At that point the renderer failed and the app appeared to crash.

   However, the debug logs show that the sidecar/server had actually died much earlier.

   Timeline from the exported debug bundle:

   03:12:52
   OOM error in V8:
   CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
   

   After this point, server.log stops completely.

   The UI remained alive for roughly another 20 minutes.

   Later:

   03:29:02
   TypeError: Failed to fetch
   

   and finally around:

   03:33:07
   fatal renderer error
   TypeError: Failed to fetch
   

   So clicking "View reasoning summary" does not appear to cause the original OOM. It seems to expose an already-dead sidecar by triggering a request to the local server.

   This suggests there may be two related problems:

   • the sidecar/server memory leak eventually causes a V8 OOM;
   • after the sidecar dies, Desktop does not immediately detect/recover from the failure, leaving the UI in a "zombie" state until another action attempts to contact the server.

   This reproduction was very consistent from the user side: the session first stopped progressing, then a later UI action caused the visible failure.

   I can provide the sanitized debug bundle if useful.
8. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
9. thdxr

   closed this as not plannedon Oct 11, 2026