Electron renderer unresponsive / crash due to ResizeObserver loop storm (layout thrashing) #38296

Activity

1. github-actions

   assigned

   Brendonovich

   on Jul 22, 2026
2. github-actions commented on Jul 22, 2026

   

   github-actionsBot

   on Jul 22, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Bug]: Desktop renderer crashes from ResizeObserver feedback loop on rapid chat-list updates #33712: Desktop renderer crashes from ResizeObserver feedback loop (same error flood, same renderer crash pattern)
   • [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 (same version, same symptoms, also on Windows)
   • [Desktop] ResizeObserver loop causes high CPU usage (renderer process) #34289: ResizeObserver loop causes high CPU usage (renderer process)

   If your issue is covered by one of the above, please add any additional information there instead of opening a new report. If you believe your case is distinct, please update this issue with:

   • Steps to reproduce (what specifically triggered the crash — e.g. pasting a large log)
   • Operating System (the dedicated field)
   • Terminal (the dedicated field)

   These fields were left as _No response_ placeholder text, which makes it harder to triage and reproduce the issue.
3. Lightningxxl commented on Sep 19, 2026

   

   Lightningxxl

   on Sep 19, 2026

   More actions

   Adding quantitative data from a real-world macOS case (Desktop 1.18.31, Apple M3, external 2560x1600 @160Hz HiDPI). Confirms the loop is self-sustaining and independent of streaming activity:

   • Renderer process accumulated 40h02m CPU time over 53h of uptime (~76% average); GPU helper 36h19m (~68%). The burn is continuous, not bursty.
   • renderer.log over the same 2d5h window: 1416 ResizeObserver loop completed with undelivered notifications errors. Per-minute breakdown by concurrent streaming sessions (correlated from the server log):
     • 0 streaming sessions: 141 minutes with errors, mean 9.8/min, peak 82/min
     • 1 session: 5 min, mean 2.4/min
     • 2+ sessions: 8 min, mean 3.4/min
     • Streaming was active in only ~9% of minutes in the window.
   • So the error storm (and the CPU burn) runs while nothing is streaming - the loop is self-sustaining once entered, matching the "ongoing condition" description in [Desktop] UI freezes after agent turns finish — renderer stuck in ResizeObserver loop; only force-quit + relaunch recovers #43355.
   • After force-quit + relaunch: first error 26 seconds after launch; 25 errors in the first 2 minutes; renderer/GPU back to ~37-60% CPU within 2 minutes. Restart does not clear the condition.

   This suggests the dominant cost is the idle self-sustaining loop rather than streaming-driven re-rendering, so the rAF-defer / size-delta threshold guard proposed in #33712 would remove most of the sustained burn.
4. neriousy

   marked [Desktop] UI freezes after agent turns finish — renderer stuck in ResizeObserver loop; only force-quit + relaunch recovers #43355 as a duplicate of this issue on Oct 1, 2026
5. jdsalasca commented on Oct 4, 2026

   

   jdsalasca

   on Oct 4, 2026

   More actions

   Additional reproduction: Windows, OpenCode Desktop 1.18.34

   I found the related reports #43355, #48633, and #52706. This looks related to the renderer/UI-freeze reports, so I am adding this reproduction here rather than opening another issue. The logs show events around the same period, but they do not prove that the ResizeObserver warnings caused the failed tab switches.

   Environment

   • OpenCode Desktop: 1.18.34, packaged
   • OS: Windows (OS build not recorded)
   • Recurred on October 3–4, 2026 (America/Bogota local time)
   • Multiple session tabs were open

   Steps / observed behavior

   1. Keep multiple session tabs open in Desktop.
   2. While an assistant turn is in progress (one captured occurrence showed the progress spinner and Stop control), click another session tab in the title bar.
   3. Intermittently, the visible conversation stays on the current session and the click does not switch to the other tab.
   4. Restarting the app restored normal behavior temporarily, but the same symptom later returned.

   Expected: Clicking another session tab activates and displays that session promptly.

   Actual: The current session remains displayed after clicking another tab. In the captured occurrence, the assistant turn was still visibly in progress.

   Relevant renderer.log excerpts (October 4, local time):

   [2026-10-04 10:10:06.806] [error] (renderer) fatal renderer error {
     error: 'TypeError: Failed to fetch
       at fetch (oc://renderer/assets/main-BvOkAAhO.js:161246:45)
       at request (oc://renderer/assets/main-BvOkAAhO.js:52359:24)
       at async Object.get (oc://renderer/assets/main-BvOkAAhO.js:66234:24)',
     url: 'oc://renderer/index.html',
     version: '1.18.34',
     platform: 'desktop',
     os: 'windows'
   }
   [2026-10-04 10:10:06.954–10:10:06.973] [error] Uncaught (in promise) TypeError: Failed to fetch
   [2026-10-04 10:10:09.754] [warn] addRange(): The given range isn't in document.
   [2026-10-04 10:14:44.740] [error] ResizeObserver loop completed with undelivered notifications.
   

   I counted 36 ResizeObserver warnings in this renderer log (not hundreds per second). The renderer also logged four unhandled Failed to fetch rejections immediately after the fatal error.

   Sidecar observations: main.log recorded the local server as ready earlier in the run. During later diagnosis, its process and loopback listener were still present and there was no sidecar-exit entry. An unauthenticated health request returned 401, so I could not confirm whether authenticated renderer requests were succeeding at the time of the freeze.

   Could someone check whether the renderer’s tab-selection path remains responsive after a failed request, and compare this failure with the ResizeObserver feedback-loop reports? The current evidence identifies a renderer fetch failure and coincident layout warnings; it does not establish which one, if either, is the root cause. I can provide a redacted debug bundle if a maintainer needs it.
6. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
7. thdxr

   closed this as not plannedon Oct 11, 2026