[Bug]: Desktop v1.18.4 ResizeObserver loop + UI freeze also affects old layout (not only v2)

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 createResizeObserver calls in packages/app/src/pages/session/composer/session-composer-region-controller.ts:99, session.tsx:1171, session.tsx:1509 are 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 at localhost:20128
• 5 active local worktrees
• Provider: opencode-go, model: MiniMax-M3

Steps to reproduce

1. Install OpenCode Desktop 1.18.4 on Windows 11.
2. In Settings → Interface, set the temporary "Use old interface" toggle. Save. Restart the app.
3. Open ≥3 local projects so the project list is populated.
4. Send a message with image attachments. Let the model respond.
5. After ~30–60 s, observe renderer.log flooding with ResizeObserver loop completed with undelivered notifications.
6. 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.
7. Recovery: taskkill /F /IM OpenCode.exe then restart. The lost message is gone (never sent).

Expected

• No ResizeObserver errors in renderer.log on 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 ResizeObserver errors in 344 s (avg 6.6 s, peak 16 in any 5 s window).
• main.log clean: sidecar ready in 2.4 s, no errors.
• crash.log and Crashpad/ empty (renderer hangs, does not crash).
• 6–7 OpenCode.exe processes 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-256 78f063d3708ac5783e6237f1d315ec992d4a602232b13cd62f14bb20bb03a866)
• main.log, crash.log, network.log in 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 #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)

1. When UI freezes: kill all OpenCode.exe and restart. Re-send the lost message.
2. Lock window size after launch; do not resize.
3. Send a short priming message within ~5 s of UI ready to anchor the layout before observers fire.

Related

• #33712 — original root-cause analysis (v2 composer dock)
• #31594 — execEditLength renderer freeze
• #28844 — constructMessageRows SolidJS loop on large sessions