[Bug]: Desktop renderer crashes from ResizeObserver feedback loop on rapid chat-list updates #33712

Activity

1. github-actions

   assigned

   Brendonovich

   on Jun 24, 2026
2. RockingSisyphus commented on Jun 26, 2026

   

   RockingSisyphus

   on Jun 26, 2026

   More actions

   I'm seeing the same issue on Linux (v1.17.11, Electron 42.3.3), so this is cross-platform.

   Full evidence gist: https://gist.github.com/RockingSisyphus/53ceef8127c47871d5b0493be9842450

   TL;DR: 3,840 out of 4,030 renderer.log lines are ResizeObserver errors (95.3%). Three crash dumps collected within 24 hours. The feedback loop is triggered by dock/composer resizing, no plugin needed.

   The cascade originates from three co-located createResizeObserver calls that fire simultaneously when the composer dock resizes:

   1. packages/app/src/pages/session/composer/session-composer-region-controller.ts:99 — calls getBoundingClientRect() in every observer callback, zero throttling
   2. packages/app/src/pages/session.tsx:1171 — fires scheduleScrollState() + fill() on content area resize
   3. packages/app/src/pages/session.tsx:1509 — fires scrollToEnd() + scheduleScrollState() + fill() on prompt dock height change

   The feedback chain: dock resize → #1 fires → re-layout → #2 fires → content resize → #3 fires → more layout → back to #1. All within a single animation frame.

   Peak burst: 20+ errors/second, sustained for ~30 seconds producing ~200 errors in one burst. Under load this freezes the renderer → Electron watchdog kills it → crash dump.

   Crashpad pending dumps: 235 KB, 260 KB, 421 KB (Jun 26-27).

   👍React with 👍1Reacted by Moore2877
3. IvoDimitrovPro commented on Jul 20, 2026

   

   IvoDimitrovPro

   on Jul 20, 2026

   More actions

   Update from real-world Windows 11 session — 2026-07-20

   Context: Reconfirming this bug is still present in v1.18.4 (latest, installed today). One new signal below that wasn't in the original report.

   Environment

   • OpenCode Desktop 1.18.4 (Electron 42.3.3 / Chromium 148), installed 2026-07-20 18:10
   • OS: Windows 11
   • Layout: old layout (oldLayoutEligible: true) — see "new signal" below
   • Plugins: plugin: [] (empty, ruled out)
   • 5 active local worktrees
   • Provider: opencode-go, model: MiniMax-M3

   Reproduction confirmed (this run, 2026-07-20 23:32 UTC)

   1. C:\Users\ivo\AppData\Roaming\ai.opencode.desktop\logs\20260720T203241\
   2. renderer.log: 53 ResizeObserver loop completed with undelivered notifications lines in 344 s.
   3. Peak burst: 16 errors in any 5 s window (avg 6.6 s between errors).
   4. main.log clean: sidecar ready in 2.4 s, no errors.
   5. crash.log and Crashpad empty — the renderer hangs, it does not crash.
   6. 6–7 OpenCode.exe processes accumulate, the main process is ~320 MB RSS.
   7. UI freezes on the "Thinking" indicator after a few minutes. Kill all OpenCode.exe + restart re-enables input.

   🆕 New signal not in the original report

   The original report scoped this to the v2 composer dock. I am on the old layout (oldLayoutEligible: true confirmed in opencode.settings), and I still see the same ResizeObserver flood plus the same UI freeze. This suggests the bug also exists in the legacy session page, not only in the new v2 composer. If your fix only touches the three createResizeObserver calls in the v2 composer, please also check whether the same or similar observer cluster exists in the legacy packages/app/src/pages/session_legacy/ (or whatever the v1 code path is called).

   What I see in the wild that you might not see in your repro

   • The UI does not always show a "Thinking" indicator during the freeze. Sometimes the input box becomes completely unresponsive — I cannot click the send button, the model dropdown doesn't open, nothing. Other times the "Thinking" indicator is rendered but the model is not actually producing tokens (and re-sending the same message after restart shows the previous one was never sent at all — it was lost on freeze).
   • The freeze is intermittent: I can send 2–3 messages successfully, then the next one hangs. Not every message is affected.
   • This pattern is independent of model, session, or workspace. Repro: send image attachments + a multi-paragraph prompt.

   Temporary workaround I'm using

   1. When frozen: taskkill /F /IM OpenCode.exe, then restart. Re-send the lost message.
   2. Lock window size after launch; do not resize (avoids triggering the observer chain).
   3. Send a short "priming" message (e.g. a single character) within ~5 s of UI ready to anchor the layout before observers fire.

   Data

   • Diagnostic backup: opencode-diagnostic-2026-07-20-233222 (settings, global.dat, draft, user opencode.json, window-state)
   • renderer.log SHA-256: 78f063d3708ac5783e6237f1d315ec992d4a602232b13cd62f14bb20bb03a866
   • Full bug draft with formatting: I have a local markdown copy ready to attach if useful.

   Thanks for picking this up — happy to provide more logs or run any test build you want.
4. rafaelbn commented on Jul 23, 2026

   

   rafaelbn

   on Jul 23, 2026

   More actions

   Confirmed on OpenCode Desktop 1.18.4 for Windows without configured plugins or MCP servers.

   My local renderer logs contain 3,535 occurrences of ResizeObserver loop completed with undelivered notifications across 13 launches. The UI becomes completely unresponsive while the sidecar remains healthy and the task may continue running.

   This confirms that the feedback loop is not dependent on the plugin mentioned in the original report.

   Full anonymized evidence and environment details:
   #37997 (comment)

   👍React with 👍1Reacted by IvoDimitrovPro
5. github-actions commented on Sep 22, 2026

   

   github-actionsBot

   on Sep 22, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
6. github-actions

   closed this as not plannedon Sep 22, 2026