desktop: renderer unresponsive when adding a project — request fan-out + reactive recompute storm (regression 2.0.25 → 2.0.28) #55191

Summary

OpenCode Desktop 2.0.28 (Windows) hangs with "renderer unresponsive" every time a new project is added, regardless of folder or disk. Reproduces with a fully clean config (plugins: [], all MCP servers disabled). Regression: 2.0.25 (previous version) did not fatally hang on the same action.

Environment

• opencode version: 2.0.28 (Desktop + bundled opencode-cli sidecar 2.0.28)
• OS: Windows_NT 10.0.26100 (win32 x64)
• Terminal: Unavailable: terminal environment variables are not set
• Shell: C:\Windows\system32\cmd.exe
• Install/channel: release (installed via opencode-desktop-win-x64.exe from opencode.ai)
• Active plugins: ./plugins/lf-guard, ./plugins/scrollback-inbox, K:/Projects/OpenCode_Web_Search — but reproduced with "plugins": [] and every MCP server disabled/removed, so plugins are excluded as the cause.

Reproduction

1. Open OpenCode Desktop 2.0.28 on Windows.
2. Add a new project (any folder, any disk — reproduced with an empty folder K:\Projects\OpenCode_Agents, plus folders on other disks).
3. The window freezes; Electron shows the "renderer unresponsive — restart or wait?" dialog.

Frequency: consistent — every attempt, on any folder. Produces 10+ app restarts a day.

Expected Behavior

Adding a project opens it promptly, as in 2.0.25.

Actual Behavior

Renderer main thread blocks in a reactive re-render loop. Sampled stacks (window.log):

at Ine (main-*.js:682)          # store eviction: filter + sort by lastAccessAt
at Array.filter / Array.sort
at String.replaceAll (qE)       # path normalization (iD) inside filter callbacks
at Proxy.map over child stores (684:36017)

renderer.log shows repeated [server-request-queue] server thrashing detected, starting ~13s after launch and recurring in every session.

Network log for one 80-second session (~3.3 MB): the renderer fans out across all 24 known projects — e.g. /api/provider x84, /api/model x80, /api/command|mcp|skill|agent|reference x56 each, /api/session/ses_* x8-12 per session, /api/worktree/refresh x19, /api/fs/list|find dozens. Individual endpoints are fast (<0.5s, <1KB via CLI probes); the volume of responses each invalidating reactive queries + persisted per-project stores appears to wedge the renderer.

The project row itself IS created server-side (visible in opencode.db project table) — only the UI hangs.

Additional Context

• Updated 2.0.25 -> 2.0.28 today (binary timestamp 2026-10-13 11:01 UTC+3); the fatal hang on project-add started with 2.0.28. server thrashing detected warnings existed on 2.0.25 (Oct 12 logs) but did not block the UI.
• Ruled out during diagnosis (each re-tested, hang unchanged):
  • custom MCP servers (youtube-transcript via uvx --from git+..., rea with 170 tools, scrollback, archicad-tapir — all disabled/removed; note: mcp.servers.*.enabled: false is silently ignored in V2, correct key is disabled: true)
  • custom plugins (lf-guard, scrollback-inbox, web-search)
  • project content (empty folder hangs too) and disk health (all drives present)
  • cache (%USERPROFILE%\.cache\opencode cleared)
• Data scale that may aggravate it: 24 projects in picker, opencode.db ~807 MB + 59 MB WAL (~20k session messages, ~48k parts).
• Full debug-log exports (main/renderer/window/crash/network netlog + 48 MB server log, 2 sessions: before and after clean-config repro) available on request (~4.5 MB zips).
• Workaround: run the staged sidecar TUI directly (...\ai.opencode.desktop\cli\2.0.28-x64\opencode-cli.exe from the project directory) — server-side API is healthy; only the Desktop renderer hangs.