desktop: renderer still spins and ResizeObserver storms on 2.0.24 after adding a project #53859

Summary

Updating from 2.0.19 to 2.0.24 eliminates the version-flip service-restart cycle, but the renderer-side freeze mechanism is not fixed. After adding a project, the renderer process still spins at a significant fraction of a CPU core and emits a continuous stream of ResizeObserver loop completed with undelivered notifications errors. The watcher subscription set has also grown: the service now watches both drive roots (C:\ and D:\) instead of only the data drive root.

Environment

• opencode version: 2.0.24 (desktop app, bundled CLI, and update feed all agree on 2.0.24)
• OS: Windows_NT 10.0.19045 (win32 x64)
• Terminal: OpenCode desktop app (Electron), not the TUI
• Shell: C:\WINDOWS\system32\cmd.exe
• Install/channel: packaged desktop release (%LOCALAPPDATA%\Programs\@opencodedesktop), channel latest, allowDowngrade: true
• Active plugins: none — no opencode.json / opencode.jsonc in any global or project config location
• Registered projects at time of report: 6

Reproduction

1. Install the OpenCode desktop app at version 2.0.24 and add a few project folders (3 or more).
2. Launch the desktop app. Let it reach the project list.
3. Click "+ Add project" and select a folder in the directory picker.
4. Observe the renderer process consuming CPU continuously and the ResizeObserver loop error flooding the renderer log.
5. Confirm the background service stays healthy throughout — the local API responds normally.

Expected Behavior

The new project appears in the project list and the app remains responsive. Adding a project should not cause sustained renderer CPU usage or layout-loop errors.

Actual Behavior

1. Version-flip cycle is resolved

The installed executable is now consistently 2.0.24 and the updater reports up-to-date on every launch. No further version-mismatch / missing service restarts are observed. This part of the original report is fixed.

2. Watcher subscription now covers both drive roots (new in 2.0.24)

When a project directory is opened, the service subscribes a watcher to every ancestor directory up to and including both drive roots, plus the user profile directory:

[info] watcher subscribe path="C:\\"                            type=entries
[info] watcher subscribe path="C:\\Users"                       type=entries
[info] watcher subscribe path="<user profile>"                  type=entries
[info] watcher subscribe path="D:\\"                            type=entries
[info] watcher subscribe path="D:\\<parent>"                    type=entries
[info] watcher subscribe path="D:\\<parent>\\<child>"           type=entries
[info] watcher subscribe path="<project>\\AGENTS.md"            type=file

In 2.0.19 only D:\ was watched. In 2.0.24 C:\ is added, so both drive roots are now monitored. Each added project extends this chain. Watching a drive root is expensive on Windows and increases the event volume the renderer must absorb.

3. Renderer still spins on pure computation

Live CPU sampling over a 15-second window while the app is idle after project addition:

The renderer does not reach the 80–100% seen in 2.0.19, but it still consumes a non-trivial share of a core indefinitely while idle. The reduction is consistent with the version-flip restart loop being gone, not with the underlying reactive-loop defect being fixed.

4. ResizeObserver layout-loop errors continue

The renderer log shows a continuous stream of:

[error] ResizeObserver loop completed with undelivered notifications.

Error counts per app-launch log directory, comparing 2.0.19 and 2.0.24 sessions:

The 2.0.24 sessions still produce dozens of layout-loop errors per launch. The errors arrive in bursts (up to 16 consecutive lines within a single second), indicating a repeating layout feedback loop rather than a one-off measurement glitch.

5. Worktree discovery still fails for every non-git project

Unchanged from 2.0.19:

[warn] worktree discovery failed directory="<project>" strategy=git error=Worktree.DirectoryUnavailableError

Reported once per project per location boot, including twice within ~80ms on some boots.

Additional Context

• Frequency: reproduced on every 2.0.24 launch with 3+ registered projects. Not intermittent.
• Recovery: killing the desktop OpenCode.exe processes clears the freeze. Data is not lost.
• Workarounds that avoid the issue:
  • Launch via the CLI in the target directory instead of using "+ Add project".
  • Keep the registered project count low (2–3).
• Not the cause: the local service API stays responsive throughout (/api/info, /api/project, /api/session all return normally), so this is isolated to the desktop renderer.
• Renderer asset hashes and window IDs have been redacted from log samples above.
• Change from 2.0.19 report: the version-flip service-restart cycle is resolved in 2.0.24. The remaining issues are the renderer reactive loop, the expanded watcher set covering both drive roots, and the persistent ResizeObserver layout-loop errors.