Repository navigation
Description
Summary
The ResizeObserver loop completed with undelivered notifications flood + the "Thinking"-state UI freeze documented in #33712 is not limited to the new v2 layout. I am running the old layout (oldLayoutEligible: true in opencode.settings) and the bug reproduces identically.
This means either:
- The three
createResizeObservercalls inpackages/app/src/pages/session/composer/session-composer-region-controller.ts:99,session.tsx:1171,session.tsx:1509are also mounted by the legacy session page, or - A separate, similar observer cluster exists in the legacy code path that the original repro missed.
A fix that only patches the v2 composer will leave old-layout users (including anyone who chose "Use old interface" in the v1.18.0 transition) still broken.
Environment
- OpenCode Desktop 1.18.4 (Electron 42.3.3 / Chromium 148), installed 2026-07-20 18:10
- Windows 11
opencode.settings:{ "tauriMigrated": true, "pinchZoomEnabled": false, "oldLayoutEligible": true, "firstLaunchOnboardingComplete": true }opencode.json:plugin: [], MCP servers (zread, web-search-prime, web-reader), 9router atlocalhost:20128- 5 active local worktrees
- Provider: opencode-go, model: MiniMax-M3
Steps to reproduce
- Install OpenCode Desktop 1.18.4 on Windows 11.
- In Settings → Interface, set the temporary "Use old interface" toggle. Save. Restart the app.
- Open ≥3 local projects so the project list is populated.
- Send a message with image attachments. Let the model respond.
- After ~30–60 s, observe
renderer.logflooding withResizeObserver loop completed with undelivered notifications. - After several minutes, the UI may freeze: the input box becomes unresponsive, the send button does nothing, and in some cases the "Thinking" indicator is shown but the model never actually produced output.
- Recovery:
taskkill /F /IM OpenCode.exethen restart. The lost message is gone (never sent).
Expected
- No
ResizeObservererrors inrenderer.logon the old layout either. - UI stays responsive for long sessions.
- A hung renderer recovers automatically or surfaces a reconnect prompt.
Actual (this run, 2026-07-20 23:32 UTC)
- 53
ResizeObservererrors in 344 s (avg 6.6 s, peak 16 in any 5 s window). main.logclean: sidecar ready in 2.4 s, no errors.crash.logandCrashpad/empty (renderer hangs, does not crash).- 6–7
OpenCode.exeprocesses accumulate, main process ~320 MB RSS. - UI freezes intermittently. Sometimes the freeze presents as "Thinking" stuck; sometimes the input box stops responding entirely with no indicator. Pattern is not model-, session-, or workspace-specific.
Evidence
C:\Users\ivo\AppData\Roaming\ai.opencode.desktop\logs\20260720T203241\renderer.log(5830 bytes, SHA-25678f063d3708ac5783e6237f1d315ec992d4a602232b13cd62f14bb20bb03a866)main.log,crash.log,network.login the same folder (clean)- Diagnostic backup:
C:\Users\ivo\Products\Universe-Memory-Protocol\Backups\opencode-diagnostic-2026-07-20-233222\(settings, global.dat, draft, user opencode.json, window-state) - Updated the existing [Bug]: Desktop renderer crashes from ResizeObserver feedback loop on rapid chat-list updates #33712 with these same data points.
Suggested fix
In addition to the requestAnimationFrame + size-delta guards already suggested in #33712, please also audit the legacy session page for any createResizeObserver cluster that may have been carried over from v1. The simplest path is to wrap the global createResizeObserver helper in packages/app/src/.../utils/ (if it exists) so all observers automatically inherit the rAF defer + threshold guard, instead of patching each call site individually.
Workaround (until fixed)
- When UI freezes: kill all
OpenCode.exeand restart. Re-send the lost message. - Lock window size after launch; do not resize.
- Send a short priming message within ~5 s of UI ready to anchor the layout before observers fire.
Related
- [Bug]: Desktop renderer crashes from ResizeObserver feedback loop on rapid chat-list updates #33712 — original root-cause analysis (v2 composer dock)
- Desktop app renderer freezes/crashes repeatedly #31594 —
execEditLengthrenderer freeze - Desktop app renderer hangs indefinitely on sessions with large message counts #28844 —
constructMessageRowsSolidJS loop on large sessions
Activity
github-actions commentedon Jul 20, 2026
This issue might be a duplicate of existing issues. Please check:
rafaelbn commentedon Jul 23, 2026
I can confirm this issue on OpenCode Desktop 1.18.4 for Windows (64-bit, build 26200; Electron 42.3.3).
Observed behavior:
Local evidence:
ResizeObserver loop completed with undelivered notificationsacross 13 renderer logs from July 15-23.main.logis clean and reports the sidecar ready in under two seconds.This closely matches the reported renderer feedback-loop behavior. I can provide anonymized logs or additional diagnostics if useful.
github-actions commentedon Sep 22, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.