Skip to content

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

New issue
New issue
Closed as duplicate
Closed as duplicate
[Desktop] UI freezes after agent turns finish — renderer stuck in ResizeObserver loop; only force-quit + relaunch recovers#43355
Assignees
Hona

Description

@StarryJinda
StarryJinda
opened on Aug 19, 2026

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)

Activity

  1. StarryJinda
    changed the title [-]UI freezes after agent turns finish — renderer stuck in ResizeObserver loop; only force-quit + relaunch recovers[/-] [+][Desktop] UI freezes after agent turns finish — renderer stuck in ResizeObserver loop; only force-quit + relaunch recovers[/+] on Aug 19, 2026
  2. github-actions
    assigned
    Hona
    on Aug 19, 2026

  3. github-actions commented on Aug 19, 2026

    @github-actions
    github-actionsBot
    on Aug 19, 2026 – with GitHub Actions
    Contributor

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

  4. Morningstar202604 commented on Aug 25, 2026

    @Morningstar202604
    Morningstar202604
    on Aug 25, 2026

    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.

  5. Morningstar202604 commented on Aug 28, 2026

    @Morningstar202604
    Morningstar202604
    on Aug 28, 2026

    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.

  6. jtcorthorn commented on Sep 1, 2026

    @jtcorthorn
    jtcorthorn
    on Sep 1, 2026

    Confirming this freeze pattern on Windows 11 (RTX 5070, GPU drivers clean — separate issue already ruled out; all processes responding, renderer main-thread blocked; force-quit is the only recovery).

    Differential signal I have not seen reported: on every launch since v1.18.21 through v1.18.25 (latest), renderer.log shows:

    [2026-09-01 11:18:53.919] Slow network is detected. Fallback font will be used while loading: oc://renderer/assets/Inter.ttf
    [2026-09-01 11:18:55.105] ResizeObserver loop completed with undelivered notifications.

    The oc:// protocol handler appears to exceed Chromium's slow-font-load threshold → fallback font metrics → reflow that feeds the observer cluster analyzed in #33712 (session-composer-region-controller.ts:99 unthrottled getBoundingClientRect(), plus session.tsx:1171 / session.tsx:1509). Clearing Cache/GPUCache does not eliminate the warning.

    This gives a deterministic ~2s prelude to the loop on every launch, which may be useful for repro. Happy to attach full renderer.log bundles if helpful.

  7. cloudcat214 commented on Sep 19, 2026

    @cloudcat214
    cloudcat214
    on Sep 19, 2026

    Confirming this is still reproducing on OpenCode Desktop 1.18.31 (Windows, Electron) — i.e. it did not stop at 1.18.25.

    Quantified from a 3-day window of window.log / renderer.log on one machine:

    • 15 renderer unresponsive events (2026-09-16 x13, 09-17 x1, 09-18 x1), durations 0.93 s - 34.55 s, median approx. 5.8 s. Recovery in practice was force-quit / relaunch, same as described here.
    • renderer.log accumulated roughly 119,186 ResizeObserver loop completed with undelivered notifications entries across sessions — the loop is continuous, not burst-only.
    • Timing correlation (freeze time +/- 25 s, from the server-side stream log): the 2026-09-18 11:28:25 freeze (1.66 s) happened while 6 sessions / 16 concurrent streams were active, i.e. it escalates under concurrent streaming.

    Stack samples from the same freezes also land on the timeline-reconciliation path reported in #48434 (reuseTimelineRows -> Equal.equals -> structure/hash/compareObjects), so the two reports look like the same underlying reactivity/rendering problem seen from different angles; a fix for the recomputation side is drafted in #48435 and is not merged yet.

    Happy to share the raw event log if that helps pin the ResizeObserver escalation.

  8. Lightningxxl commented on Sep 19, 2026

    @Lightningxxl
    Lightningxxl
    on Sep 19, 2026

    Confirming the "ongoing condition" and adding post-restart data (Desktop 1.18.31, macOS, Apple M3):

    • The ResizeObserver storm runs continuously even with zero active sessions: in a 2d5h window, 141 of the error-bearing minutes had no streaming activity at all (mean 9.8 errors/min, peak 82/min), vs 2.4-3.4/min when sessions were streaming.
    • After force-quit + relaunch the condition returns almost immediately: first error 26s after launch, 25 errors within 2 minutes, renderer/GPU processes back to ~37-60% CPU within 2 minutes. So the freeze-prone state is re-entered within seconds of startup, not only after turns finish.
    • Renderer accumulated ~40h CPU over 53h uptime (~76% average), consistent with the loop running essentially the whole time.

    This matches the timeline pattern reported here (error flood escalating into full freeze) and suggests the loop is entered at startup/first render and persists; turn completion is one escalation trigger among several.

  9. nattanfx commented on Sep 20, 2026

    @nattanfx
    nattanfx
    on Sep 20, 2026

    Draft comment for #43355

    Adding a possibly related report from OpenCode Desktop 1.18.31 on Windows (OS build 26200). This happened twice on my first day of use, September 20, 2026.

    Observed behavior

    The conversation stopped visually updating during a coding task: it continued displaying “Pensando” (Thinking), the Stop control, an unfinished Edit entry, and 0 of 4 tasks completed. The final response never appeared during the observation period, although the work had finished in the background. Windows reported the OpenCode processes as responding; this does not establish that the renderer itself was responsive.

    Evidence from read-only local inspection

    • The installed desktop package and session both report version 1.18.31.
    • The persisted final assistant message completed at 2026-09-20 15:40:20 UTC-3, with finish: "stop".
    • The final todowrite tool call completed, with all four items marked completed.
    • The final response text was already saved in SQLite, and the task's output report existed on disk.
    • Around 15:50 UTC-3, the live window still showed the earlier 0/4 and Thinking state, matching the original screenshot. The mismatch persisted for approximately ten minutes after recorded completion.

    Renderer log

    The affected app session, launched at 12:44 local time, contains 26 occurrences of ResizeObserver loop completed with undelivered notifications. Examples include 15:35:54.225, 15:36:51.076 and 15:52:09.526 (UTC-3). The next app session also logs this error immediately after startup at 15:52:31.

    This does not establish a sustained error storm at the exact freeze time, and I cannot confirm that ResizeObserver is the cause. I am adding this here because the completed backend work versus stale desktop UI resembles this issue.

    Context and reproduction limits

    • Build agent; UI model label: Muse Spark 1.3 Free; reasoning setting: Xhigh.
    • Local workspace is inside a OneDrive-synced directory.
    • Observed sequence: ask the agent to continue a multi-step coding task involving file edits and tests; the UI stops advancing while subsequent operations and the final answer are saved.
    • Intermittent; no minimal deterministic reproduction yet. Plugin involvement, sleep/network triggers, and whether relaunch alone restores the final response have not been verified.

    Expected: show the saved final response and completed task list, clear the running state, or recover/report a synchronization failure.

    No full database, authentication files, screenshot, or private project contents are attached.

  10. neriousy commented on Oct 1, 2026

    @neriousy
    neriousy
    on Oct 1, 2026
    Member

    Closing as a duplicate of #38296. Same Desktop renderer freeze caused by a ResizeObserver loop. Tracking in #38296.

  11. neriousy
    closed this as a duplicateof Electron renderer unresponsive / crash due to ResizeObserver loop storm (layout thrashing) #38296 on Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions