[Desktop] UI freezes after agent turns finish — renderer stuck in ResizeObserver loop; only force-quit + relaunch recovers

[StarryJinda]

Description

The OpenCode Desktop app (Electron, v1.18.18) freezes: the window becomes completely unresponsive (no click/typing reaction, no rendering updates) shortly after an assistant turn finishes. The backend core loop is still alive — it finishes turns and logs normally — only the renderer UI is stuck. The only way to recover is force-quitting and relaunching the app.

Happened twice within ~20 minutes (18:22–18:29 and 18:37–18:40 local time), each time ending with a forced app restart. The renderer log around both freezes is flooded with ResizeObserver loop completed with undelivered notifications, and the same errors keep occurring continuously even during normal operation (634 occurrences in the current session within 3.5 hours), so the layout loop is an ongoing condition that periodically escalates into a full freeze.

Timeline (local time):

• 18:21:55 – agent turn # 1 completes (exiting loop in core log); renderer floods with ResizeObserver errors; window freezes for ~7 min.
• 18:29:05 – force-quit and relaunch (main.log: new app start).
• 18:31:41 – agent turn # 2 completes; renderer floods again (18:31:38–18:35:31).
• 18:36:53 – agent turn # 3 completes; window freezes again.
• 18:40:10 – force-quit and relaunch again. Freezes stop only after restart.

Plugins

No response

OpenCode version

Desktop app 1.18.18 (auto-updater reports this as latest).

Steps to reproduce

Not 100% reproducible, but the pattern observed:

1. Open a large project folder (in my case a ~5 GB directory tree with ~2,400 files inside a Nutstore-synced folder on Windows 10).
2. Send a message and let the assistant turn complete.
3. Within seconds after the turn finishes, the window freezes for 3–7 minutes; input and rendering stop. The agent's own turn history keeps being written to the core log during the freeze, so only the UI is affected.
4. Force-quit and relaunch the app — the session then resumes normally.

Trigger seems related to rendering completed assistant messages, possibly aggravated by a very large project tree / long messages.

Additional context

Some observations from my logs that may help diagnose:

1. Root-cause hypothesis (renderer layout loop): The freezes start exactly when a completed assistant message is rendered into the chat. DOM size oscillation (auto-resizing scroll container / streaming content) keeps invalidating layout faster than Chromium can deliver ResizeObserver notifications, starving the renderer's main thread. The main process stays alive and responsive (auto-update checks keep firing during the freezes); only the renderer is stuck, and a full app restart is the only recovery. The errors also appear continuously during normal operation (hundreds per session), so the layout loop is persistent and periodically escalates into a complete freeze.

2. Possible aggravating factors:

   • The project is a ~5.3 GB directory tree (~2,400 files) inside a Nutstore (坚果云 / Jianguoyun) sync folder on Windows. The sync driver adds I/O latency and file locks; a large tree makes every file-tree refresh and message render slower.
   • Earlier today the same app instance logged a burst of ENOENT errors: the file API repeatedly attempted FileSystem.list on a project path that no longer exists (the folder name appeared duplicated, e.g. ...\Project xxx\Project xxx, lstat -> ENOENT). This suggests stale/mismatched workspace paths are stored in the desktop app state, which can trigger repeated tree refreshes and extra renderer work.

Screenshot and/or share link

No share link available (local session). Attached: full renderer logs of the two most recent app sessions (also referenced as attachments).

• Renderer log — session 20260818T102905 (contains both freezes; app launched 18:29:05, killed 18:40:10). Path: %APPDATA%\ai.opencode.desktop\logs\20260818T102905\renderer.log

• Renderer log — session 20260818T104010 (post-restart session, current; errors continue constantly). Path: %APPDATA%\ai.opencode.desktop\logs\20260818T104010\renderer.log

20260818T104010.txt
20260818T102905.txt

Operating System

Windows 10 22H2 (build 19045)

Terminal

N/A — OpenCode Desktop app (GUI, Electron)

[github-actions]

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

• Electron renderer unresponsive / crash due to ResizeObserver loop storm (layout thrashing) #38296: Electron renderer unresponsive / crash due to ResizeObserver loop storm (layout thrashing) — same root cause and symptoms
• [Bug]: Desktop v1.18.4 ResizeObserver loop + UI freeze also affects old layout (not only v2) #37997: Desktop v1.18.4 ResizeObserver loop + UI freeze also affects old layout — directly mentions the same ResizeObserver loop
• [Bug]: Desktop renderer crashes from ResizeObserver feedback loop on rapid chat-list updates #33712: Desktop renderer crashes from ResizeObserver feedback loop on rapid chat-list updates — same feedback loop / freeze pattern
• Electron 渲染过程变得无响应，并在 window.log 中记录“渲染器无响应”。冻结持续~3秒;应用恢复了，但性能严重下降。 #40572: Electron renderer becomes unresponsive / freeze with degraded performance — similar renderer unresponsive freeze

[Morningstar202604]

Still reproducing on v1.18.23 (win32 x64, Electron 42.3.3, Chrome 148.0.7778.218, Node 24.15.0) — adding quantified data from a debug bundle covering ~2 days of desktop usage on Windows.

Error-storm scale across every session

Share of renderer.log lines that are exactly ResizeObserver loop completed with undelivered notifications.:

session start (UTC+8)	renderer.log lines	ResizeObserver errors	share
08-24 17:09	1,923	1,915	99.6%
08-24 19:27	1,257	1,256	99.9%
08-25 00:45	2,689	2,677	99.6%
08-25 02:50	50	47	94%
08-25 03:02	13	13	100%
08-25 04:32	4	4	100%
08-25 08:44	208	208	100%
08-25 08:55	4,834	4,830	99.9%
08-25 14:31	1,268	1,239	97.7%

Bursts sustain ~10 errors/second for minutes at a time (e.g. session 20260825T085543, 19:21:19–19:21:21 local), which matches the completely frozen UI described above.

Escalation into a launch crash loop

Later the same day the problem escalated: six consecutive launches between 18:11 and 18:27 produced no renderer.log at all (renderer never got far enough to log anything), and Crashpad wrote two minidumps 2 seconds apart at the end of the sequence (18:27:24, 34 MB main-process dump, and 18:27:26, 0.9 MB). Force-quit + relaunch remained the only recovery, consistent with the original report.

Side observation (probably environmental): during those launches the auto-updater failed with net::ERR_CONNECTION_TIMED_OUT after ~21 s each time.

I have the full debug bundle (text logs scanned clean of secrets) and both minidumps available if maintainers want them attached or uploaded elsewhere.

[Morningstar202604]

Update: Confirmed this matches symptoms in #38296 (ResizeObserver loop storm causing renderer unresponsiveness). The debug bundle data I shared shows identical error patterns. Suggest marking as duplicate of #38296.