Skip to content

desktop 2.x: renderer OOM-crash on launch from workspace child-store hydration loop (legacy opencode.workspace.* scopes) #52736

New issue
New issue
Closed
#55078
Closed
desktop 2.x: renderer OOM-crash on launch from workspace child-store hydration loop (legacy opencode.workspace.* scopes)#52736
#55078
Assignees
Hona

Description

@Cuteshy
Cuteshy
opened on Oct 2, 2026

Description

Desktop 2.0.22 on macOS arm64 freezes ~16 s after the window appears, then the renderer OOM-crashes:
app render process gone { reason: 'crashed', exitCode: 5 } at a 4.08 GB V8 heap. A memo over the
persisted workspace list creates one child store per workspace (child(worktree) → persist(...)),
and store creation invalidates that same memo, so it loops while allocating a new store, schema and
query observers each pass. The seed is 98 stale opencode.workspace.* scope rows in the profile's
drafts.sqlite (vs 9 live worktrees); deleting them fixes it — 5/5 clean boots, flat 21 MB heap.
Beta on the same machine and data never hangs. Same loop as #51028 (Windows 2.0.15); this adds the
crash, the seed and the fix. Usernames/paths redacted.

Plugins

None configured.

OpenCode version

Desktop 2.0.22 (also reproduced on 2.0.16 and 2.0.18); Electron 44.4.5.

Steps to reproduce

  1. Launch 2.0.22 with a desktop profile whose drafts.sqlite has accumulated opencode.workspace.*
    state rows.

  2. Wait ~20 s: renderer unresponsive in logs/<run>/window.log, then the renderer dies. Relaunching
    does not help.

  3. One scope row set (3 rows) is enough to reproduce; removing them all fixes it:

    sqlite3 "$HOME/Library/Application Support/ai.opencode.desktop/drafts.sqlite" \
  "DELETE FROM state WHERE name LIKE 'opencode.workspace.%'"

Key stack:

at Object.ME [as persist] (main-B6pJoE_b.js:21:59445)
at Object.b [as child] (…:682:6459)
at d (…:684:36898)          <- l.child(e.worktree, { bootstrap: false })
at Proxy.map (<anonymous>)
at Object.fn (…:684:37163)  <- createMemo(() => n.list().map(d))

Screenshot and/or share link

Unavailable — the renderer never becomes interactive, so /share can't run. Full bisection data and a
copy of the store are available on request.

Operating System

macOS on Apple silicon (Darwin 27.0.0, arm64)

Terminal

Unavailable — packaged Electron app launched from Finder, no TTY involved.

Activity

  1. github-actions
    assigned
    Hona
    on Oct 2, 2026
  2. github-actions
    added
    needs:complianceThis means the issue will auto-close after 2 hours.
    on Oct 2, 2026

  3. github-actions commented on Oct 2, 2026

    @github-actions
    github-actionsBot
    on Oct 2, 2026 – with GitHub Actions
    Contributor

    This issue doesn't fully meet our contributing guidelines.

    What needs to be fixed:

    • Please use the Bug Report template and provide its required Description field. The current body uses a custom “Summary” format and does not include the required field.
    • Please condense the exceptionally lengthy report into a focused description with the key reproduction details. The bug-report template warns against giant AI-generated summaries.

    Please edit this issue to address the above within 72 hours, or it will be automatically closed.

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

    • #51028: Similar Desktop startup renderer freeze while creating per-project persisted stores, with a renderer store-creation loop.

    If you believe this was flagged incorrectly, please let a maintainer know.

  4. github-actions commented on Oct 2, 2026

    @github-actions
    github-actionsBot
    on Oct 2, 2026 – with GitHub Actions
    Contributor

    Thanks for updating the issue. It now uses the Bug Report fields and includes a concrete description, reproduction context, and system information. One item remains: the report is still exceptionally long, with extensive forensic measurements, tangential findings, and implementation suggestions. Please condense it to the core symptoms, a short reproduction path, and the most useful supporting evidence so the key report is easy to review.

  5. github-actions
    removed
    needs:complianceThis means the issue will auto-close after 2 hours.
    on Oct 2, 2026

  6. github-actions commented on Oct 2, 2026

    @github-actions
    github-actionsBot
    on Oct 2, 2026 – with GitHub Actions
    Contributor

    Thanks for updating the issue. The report now includes a clear description, reproduction steps, and system information.

  7. adamczl commented on Oct 5, 2026

    @adamczl
    adamczl
    on Oct 5, 2026

    Reproduced on Windows 11 (win32 x64, build 10.0.26200) with desktop 2.0.23 — same hydration loop, different platform and exit code than the macOS report.

    Environment

    • opencode version: 2.0.23 (desktop, latest channel), bundled CLI 2.0.23, Electron 44.x
    • OS: Windows 11 Pro (10.0.26200, win32 x64)
    • Terminal: n/a (packaged Electron app)
    • Shell: cmd.exe (for diagnostics only)
    • Active plugins: none configured

    Symptoms

    The desktop app crashed repeatedly on launch — at worst every 10–20 seconds (18 log directories created between 10:08:06 and 10:17:47 on 2026-10-05 alone; 46 total crashes across 2026-09-28 → 2026-10-05, all with identical exit code). Every window.log in that period contains:

    [error] (window)  app render process gone {
  url: 'oc://renderer/index.html',
  details: { reason: 'crashed', exitCode: -1069547419 }
}

    -1069547419 = 0xC0400065 — different from the macOS exitCode: 5 OOM code, but the reason: 'crashed' signature and the launch-time window match this issue. renderer.log shows the same ResizeObserver loop completed with undelivered notifications storm (hundreds per run) right up to the crash, plus [global-sdk] event stream disconnected afterwards. The main process and v2 CLI background service stayed healthy the whole time (v2 CLI background service ready in 1–2 s in every run).

    Seed

    %APPDATA%\ai.opencode.desktop\drafts.sqlite had 125 opencode.workspace.* state rows (vs ~7 live worktrees), including 7 rows with the base64 prefix QzpcVXNlcnNc (older profile path encoding) — i.e. the same stale-scope accumulation as in the report, just more of it.

    Fix confirmed on this machine

    Following the workaround from this issue:

    sqlite3 "%APPDATA%\ai.opencode.desktop\drafts.sqlite" \
  "DELETE FROM state WHERE name LIKE 'opencode.workspace.%'"

    125 rows deleted, app relaunched: no crash, no ResizeObserver storm, no render process gone — the app has now survived 90+ seconds of active use where every previous run died within 30 seconds. Old opencode.workspace.* rows reappear only 3-per-launch in normal use; the crash loop correlates with the stale accumulation, and clearing it breaks the loop.

    Happy to share the pre-fix drafts.sqlite backup if useful for reproducing the Windows variant.

  8. Hona
    closed this as completedin #55078on Oct 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions