Desktop 2.0.15 (Windows): renderer unresponsive on every launch (main thread pinned creating per-project stores) #51028

Description

On Windows x64, desktop 2.0.15 freezes a few seconds after the window appears, on every
launch. Electron logs renderer unresponsive and the sampled stacks are entirely inside the
renderer's own JavaScript: the app builds one persisted reactive store per project
synchronously on the main thread. The window never recovers (user had to kill it each time).

The main process and the bundled v2 CLI are healthy: main.log shows
v2 CLI background service ready in ~1–2 s, no server errors, and the v2 CLI background
service stays up. Relaunching does not help. On the same machine, 2.0.6 showed the same
symptom class 6/6 launches (samples land in different chunks, same work), so this is not a
one-off.

OpenCode version

Desktop 2.0.15 (Windows x64, packaged). For reference, the 2.0.6 export from the same machine
reports Electron 42.10.1 / Chromium 148.0.7778.280 / Node 24.18.1.
Bundled CLI: 2.0.15. Renderer: oc://renderer/index.html → assets/main-C5b0PwS_.js.

Steps to reproduce

1. Install/launch desktop 2.0.15 on Windows with an existing workspace history
   (this machine: 51 projects, 71 session directories, 1,278 sessions).
2. Leave the app alone for 10–60 s.
3. Window stops redrawing; window.log gets renderer unresponsive plus sampled stacks;
   the app does not recover.

Expected behavior

Window stays responsive; per-project stores are created lazily or off the main thread.

Actual behavior

Renderer main thread saturates while creating stores for every project; UI frozen.

Evidence

window.log (run 20260924T034628, launched 10:46:28, unresponsive 10:46:59, 6 samples):

[error] (window) renderer unresponsive {
  window: '03c23a24-a395-432a-856c-051f0830558f',
  currentURL: 'oc://renderer/index.html'
}

at Object.getPrototypeOf (<anonymous>)
at da (oc://renderer/assets/main-C5b0PwS_.js:2:66760)          <- SolidJS wrap(): reactive Proxy
at Ta (oc://renderer/assets/main-C5b0PwS_.js:2:70097)          <- SolidJS createStore()
at oc://renderer/assets/main-C5b0PwS_.js:685:84935             <- g = Ta({ project, projectMeta, icon, ... }) in createChildStore()
...
at Object.C [as child] (oc://renderer/assets/main-C5b0PwS_.js:685:86639)
at d (oc://renderer/assets/main-C5b0PwS_.js:685:111932)        <- resolve(project)
at Proxy.map (<anonymous>)
at Object.fn (oc://renderer/assets/main-C5b0PwS_.js:685:112197) <- memo: f = () => n.list().map(d)

Same run, other samples:

at String.replaceAll (<anonymous>)
at sE (..main-C5b0PwS_.js:21:49375)                            <- directory normalization
at g (..:685:83350) / Array.filter / y (..:685:83951) / f      <- store-manager LRU pass per created store
at b (..:685:84805)                                            <- createChildStore(directory)
at Object.C [as child] ... at d ... at Object.fn (projects memo)

at Object.create (<anonymous>)
at dS (..:21:22888) / mS (..:21:23018) / HS (..:21:26226)      <- effect Schema encoding chain
at Object.$E [as persist] (..:21:56617 / 21:56643)             <- effect persist(): vcs / project / icon
at ..:685:84609 / 685:84165                                    <- inside createChildStore()

2.0.6 run (20260924T034326), same job in the older bundles:

at WeakMap.get / Object.getPrototypeOf
at Sg (language-D4DVEHmN.js:15:26133)                          <- SolidJS wrap() recursion
at e_ / U_ / G_ / Object.gS [as persist] (language-…:15:70413)
at wx + String.replaceAll (language-…:15:63149)
at Array.sort (runtime-…:639:50064) / Array.filter (runtime-…:639:51311)

The 2.0.6 main.log also shows imported legacy store files { imported: 27, files: [….dat…] }
right before the freeze (v1 → v2 store migration). The migrated store itself is small
(drafts.sqlite: 783 documents, largest 15 kB; largest blob 495 kB), so payload size is not
the issue.

Full logs, all samples and the annotated symbol legend (offsets resolved against
app.asar), user name redacted: https://gist.github.com/makerwitawat/c8a8efc0218d502a90c166dceee56f08

Root-cause hypothesis (from the extracted bundle, not a debugger session)

• main-C5b0PwS_.js:685:* is the workspace store manager. child(directory) →
  createChildStore (685:84805) creates per directory: 3 ×
  persist(serverWorkspace(scope, dir, "vcs" | "project" | "icon")) (each deriving an
  effect Schema encoding chain, visible above) plus another
  createStore({ project, projectMeta, icon, config, get path(), get provider(), get agent(), get command(), get reference(), get mcp(), get lsp(), get vcs(), … }).
• Each creation also runs LRU bookkeeping (f/m/h/g/y) that walks Object.keys(allStores)
  and normalizes every entry (sE) — O(n) per created store, i.e. O(n²) over the project list.
• The trigger is the projects memo let f = E(() => n.list().map(d)) (685:112197) with
  d calling l.child(worktree) (685:111932): every project is materialized synchronously
  on the renderer thread, and the memo is re-evaluated as persisted vcs/projectMeta/icon
  stores become ready.

Operating System

Windows (win32 x64), Electron 42.x build. Terminal: n/a (desktop app; the same machine's CLI
runs fine against the same DB).

Related issues

• Electron renderer unresponsive / crash due to ResizeObserver loop storm (layout thrashing) #38296 (open) — Electron renderer unresponsive / ResizeObserver loop storm (observed on this
  machine as well, in v1; kept for reference)
• Desktop: renderer unresponsive on startup — marked.js walkTokens synchronous Markdown AST traversal blocks UI thread #32452, Renderer unresponsive (freezes) with Solid.js findDOMIndex infinite loop - OpenCode 1.16.2 #31099 — closed, different code paths (Markdown AST walk, Solid findDOMIndex), same
  class of "synchronous work on the renderer main thread"