Desktop sidecar repeatedly crashes with V8 out-of-memory, causing local server red and Failed to fetch #41964

Activity

1. github-actions

   assigned

   Hona

   on Aug 12, 2026
2. github-actions commented on Aug 12, 2026

   

   github-actionsBot

   on Aug 12, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • OOM crash on startup: Event table snapshot + session revert data grow to 1.4GB, sidecar V8 process runs out of memory #38362: OOM crash on startup — sidecar V8 process runs out of memory (event table snapshot / session revert data grow to 1.4 GB)
   • OpenCode desktop v1.18.10 - V8 OOM 'Zone Allocation failed' when opening project #39825: Desktop V8 OOM 'Zone Allocation failed' when opening project
   • event table bloat from message.updated.1 causes OOM when loading old sessions #32005: Event table bloat from message.updated.1 causes OOM when loading old sessions
   • [BUG]: Windows Desktop sidecar crashes with exitCode -2147483645, then "Failed to fetch" #41714: Windows Desktop sidecar crashes with exit code, then "Failed to fetch"
   • Memory Megathread #20695: Memory Megathread (tracks all memory/OOM reports)

   If your issue is distinct (e.g. triggered under different conditions or with a different root cause), please add details that distinguish it from the above.
3. edynasty commented on Aug 21, 2026

   

   edynasty

   on Aug 21, 2026

   More actions

   Source-level root cause: Electron locks the sidecar V8 heap at ~2GB, and NODE_OPTIONS is stripped in packaged apps

   Same crash here on v1.18.19 / macOS arm64 / Electron 42.3.3. I dug into the Electron + opencode source and found why the heap can never be raised past ~2.5GB, which means this will keep crashing as long as the working set touches the limit.

   Evidence 1: utilityProcess.fork has no resourceLimits, and opencode passes empty args

   • packages/desktop/src/main/server.ts:63-69:

     utilityProcess.fork(sidecar, [], { cwd, env: createSidecarEnv(), serviceName, stdio: "pipe" })

   • Electron's electron_api_utility_process.cc:555-599 only accepts args / env / execArgv / serviceName / cwd / stdio / session / partition — no resourceLimits option exists for utilityProcess.fork.

   Evidence 2: NODE_OPTIONS is whitelist-filtered in packaged apps

   • Electron node_bindings.cc:456-517 (SetNodeOptions): when is_packaged_app is true, only --http-parser and --max-http-header-size are allowed; everything else (including --max-old-space-size) is silently dropped:

     if (is_packaged_app && !pkg_opts.contains(option)) {
       // Explicitly disallow majority of NODE_OPTIONS in packaged apps
       LOG(ERROR) << "Most NODE_OPTIONs are not supported in packaged apps.";
       continue;
     }

   • Result: launchctl setenv NODE_OPTIONS "--max-old-space-size=8192" has no effect on the sidecar. The heap stays at the default 2048MB old space (~2518MB total).

   Evidence 3: the GC trace numbers were misread

   Crash log 2435.0 (2518.3) is used(limit), not used -> new_limit. The limit never moved; 2435MB is just how much was in use when it died.

   Why CLI works but Desktop crashes

   Same workload runs at ~1.7GB heap in both, but the CLI (plain Node) has a ~4GB heap limit on this machine (and NODE_OPTIONS works there), while the sidecar's is locked at ~2.5GB. Same 1.7GB = 41% on CLI, 68% on Desktop — any burst (streaming updates, file diffs, subagents) tips it over.

   Suggested fix (for maintainers)

   1. Give the sidecar an explicit heap headroom — e.g. pass execArgv: ["--max-old-space-size=8192"] to utilityProcess.fork, or bundle the CLI binary and run the server as a detached child process (v2 mode) instead of a node.mojom.NodeService utility process.
   2. Or add a memory budget / lazy eviction for part data in the server so the working set stays bounded.

   Happy to upload a heap snapshot per the Memory Megathread instructions if that helps.
4. byJming commented on Sep 8, 2026

   

   byJming

   on Sep 8, 2026

   More actions

   Additional sanitized reproduction data for the same symptom chain:

   • Platform: OpenCode Desktop 1.18.29, Windows x64
   • Runtime: Electron 42.3.3, Node 24.15.0
   • The bundled local server ran for about 88 minutes before failure. The V8 log showed:
     • Scavenge 1359.9 (1435.0) -> 1359.9 (1435.0) MB, allocation failure
     • Scavenge 1623.4 (1698.6) -> 1623.5 (1698.6) MB, allocation failure
     • OOM error in V8: Zone Allocation failed - process out of memory
   • The utility log then reported sidecar exited { code: 0 }.
   • About six minutes later the renderer reported TypeError: Failed to fetch.
   • A Crashpad minidump identifies the failing process as Electron's node.mojom.NodeService utility process. It did not provide a useful native stack.

   The workload involved two concurrent long-running sessions, one reaching 137 agent steps, and repeated Chrome DevTools performance trace and analysis calls. This is a possible memory-pressure contributor, not a confirmed root cause. The pending operation immediately before OOM only evaluated permissions for several .json.gz edit targets; no file I/O was recorded.

   No dump or raw debug archive is attached because it contains process environment data. All paths, session identifiers, port numbers, credentials, and project-specific names have been omitted. A sanitized dump metadata extract or a targeted reproduction can be provided if useful.
5. imvenkata commented on Sep 17, 2026

   

   imvenkata

   on Sep 17, 2026

   More actions

   Same crash confirmed on macOS arm64 (v1.18.31)

   Can confirm this affects macOS arm64 / OpenCode 1.18.31 as well. The sidecar OOMs consistently ~50s after launch regardless of environment.

   Reproduction

   What we tried (none helped)

   Fix	Result
   Removed Anthropic OAuth credential	❌ Still OOM
   Cleared all workspace .dat cache files	❌ Still OOM
   Removed all 87 skills from ~/.agents/skills/	❌ Still OOM
   Trashed all old log folders	❌ Still OOM
   	❌ Rejected by Electron: Most NODE_OPTIONs are not supported in packaged apps
   	❌ Flag doesn't propagate to child; triggers GPU process + crashpad crash instead

   Logs

   Sidecar consistently exits with code 5 (SIGABRT from OOM):

   GPU process + crashpad follow after sidecar termination:

   Workaround

   CLI works fine:

   opencode run "your question"

   The raw Node.js process (CLI) has the default ~4GB heap, so the same workload fits. Only Electron's child hits the ~2.5GB wall.

   Root cause alignment

   Matches @edynasty's analysis from the comments above — the fix needs to come from the maintainers by either:

   1. Passing execArgv: ["--max-old-space-size=8192"] in utilityProcess.fork call in packages/desktop/src/main/server.ts
   2. Bundling the CLI binary and running the server as a detached child process instead of Electron's Node utility service

   Happy to provide additional logs or details.
6. imvenkata commented on Sep 17, 2026

   

   imvenkata

   on Sep 17, 2026

   More actions

   Updating with missing reproduction details that got mangled:

   macOS version: 15.7.3 arm64
   OpenCode: 1.18.31 (both CLI via Homebrew and .app bundle)
   Node.js: v22.13.1

   Sidecar OOM log:

   [19423:0917/062532.266543:ERROR:electron/shell/common/node_bindings.cc:189] OOM error in V8: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
   

   GPU + crashpad follow:

   ERROR:content/browser/gpu/gpu_process_host.cc:998] GPU process exited unexpectedly: exit_code=15
   FATAL: crashpad: Check failed: kr == KERN_SUCCESS. mach_port_request_notification: invalid capability (20)
   

   The table rows that got eaten were:

   • NODE_OPTIONS=... → rejected by Electron
   • --js-flags=... → does not propagate to utilityProcess.fork child

   Already tracking this issue. Happy to test patches if needed.
7. 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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
8. thdxr

   closed this as not plannedon Oct 11, 2026