Skip to content

desktop: idle app pins ~1 CPU core with software rendering and ResizeObserver loop (Intel macOS) #52927

New issue
New issue
Closed as duplicate
Closed as duplicate
desktop: idle app pins ~1 CPU core with software rendering and ResizeObserver loop (Intel macOS)#52927
Assignees
Hona
Labels
pending closetriaging

Description

@azhnan-dev
azhnan-dev
opened on Oct 3, 2026

Summary

OpenCode Desktop 2.0.22 (Electron) pegs roughly one full CPU core while the app
is idle. Its GPU helper runs with software rendering (--use-gl=disabled), and
renderer.log fills with ResizeObserver loop completed with undelivered notifications. On a 2-core Intel Mac this saturates the CPU and WindowServer,
making the whole system laggy.

Environment

  • opencode version: Desktop 2.0.22 (bundled opencode-cli 2.0.22). PATH CLI reports 2.0.11.
  • OS: macOS 13.6 "Ventura" (Darwin 22.6.0, x86_64), MacBookAir7,2
    • CPU: Dual-Core Intel Core i5-5350U @ 1.8 GHz (2 cores / 4 threads)
    • RAM: 8 GB
    • GPU: Intel HD Graphics 6000
  • Terminal: N/A (Electron desktop app; TERM_PROGRAM unset)
  • Shell: /bin/zsh
  • Install/channel: release desktop app (/Applications/OpenCode.app), version 2.0.22, auto-updater reports "up-to-date"
  • Active plugins: superpowers@git+https://github.com/obra/superpowers.git

Reproduction

  1. Install OpenCode Desktop 2.0.22 on macOS 13.6 (Intel, 2-core, 8 GB RAM).
  2. Launch the app and leave it idle (no prompt running, window just open).
  3. Open Activity Monitor (or run top -o cpu). Observe the OpenCode helper
    processes and WindowServer at high CPU.
  4. Inspect ~/Library/Application Support/ai.opencode.desktop/logs/<latest>/renderer.log
    for repeated ResizeObserver loop errors.

Expected Behavior

An idle OpenCode Desktop window should use very little CPU (a few percent), and
UI rendering should use the GPU (hardware acceleration) rather than a single CPU
core.

Actual Behavior

Measured on the idle app:

  • OpenCode Helper --type=gpu-process ... --use-gl=disabled:
    +9.72 s CPU over a 10 s wall window (~97% of one core, sustained).
    Note the explicit --use-gl=disabled, i.e. software rendering.
  • WindowServer: +3.96 s CPU over the same 10 s (~40% of one core).
  • opencode-cli serve --service: bursty, frequently >40% CPU.
  • Whole OpenCode process group: ~1.2 GB RAM across 5 processes.
  • renderer.log: 343 occurrences of
    ResizeObserver loop completed with undelivered notifications in a single
    session (plus more continuing over time).
  • System load average 7.61 / 5.75 / 6.24 on a 2-core machine; memory nearly
    exhausted (8 GB used, ~950 MB compressor, swap in use).

Relevant process command line (GPU helper):

/Applications/OpenCode.app/Contents/Frameworks/OpenCode Helper.app/Contents/MacOS/OpenCode Helper \
  --type=gpu-process --user-data-dir=.../ai.opencode.desktop \
  --use-gl=disabled --shared-files ...

Sample of renderer.log:

[2026-10-03 14:32:05.561] [error] ResizeObserver loop completed with undelivered notifications.
[2026-10-03 14:32:11.463] [error] ResizeObserver loop completed with undelivered notifications.
[2026-10-03 14:36:48.902] [error] ResizeObserver loop completed with undelivered notifications.

Additional Context

  • Reproducible: consistently, whenever the desktop app is running.
  • Recent change: OpenCode Desktop was installed today; the lag began right after.
  • Related observation: main.log shows an update check failing once with
    net::ERR_NETWORK_CHANGED (likely unrelated, but noted).
  • No GPU crash is logged; the --use-gl=disabled flag appears by default.
  • Workaround: quitting OpenCode Desktop drops load immediately; using the
    terminal CLI/TUI instead avoids the issue on this hardware.
  • Impact is worst on low-core machines because the software renderer competes
    with WindowServer and other Electron apps (Brave, Telegram).

Activity

  1. github-actions
    assigned
    Hona
    on Oct 3, 2026

  2. github-actions commented on Oct 3, 2026

    @github-actions
    github-actionsBot
    on Oct 3, 2026 – with GitHub Actions
    Contributor

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

    • #52706: Desktop 2.0.21/2.0.22 on macOS reports the same ResizeObserver loop errors and app unresponsiveness.
    • #34289: ResizeObserver loop errors are associated with high Desktop CPU usage.
    • #38296: Electron renderer ResizeObserver error storm leads to hangs/crashes.

  3. pial-open-source commented on Oct 12, 2026

    @pial-open-source
    pial-open-source
    on Oct 12, 2026

    Additional data point on Apple Silicon, same symptom without software rendering.

    Environment

    • opencode Desktop 2.0.27 (bundled opencode-cli 2.0.27)
    • macOS 27.0.1 (Darwin 27.0.0, arm64), Apple M4, 10 cores
    • Single external display, 3840x2560 at "looks like 1920x1280" (2x HiDPI), 60 Hz
    • Terminal: N/A (Electron desktop app)
    • Shell: /bin/zsh
    • Install/channel: release desktop app, auto-updater reports up to date
    • Active plugins: two local workspace plugins (daily backup trigger, token-usage sync); both spawn detached processes on events. Not tested with them disabled.

    Measurements

    App relaunched fresh, one session open. CPU time sampled with ps over a 10 s wall window:

    • OpenCode Helper --type=gpu-process: +3.07 s / 10 s (~31 %)
    • OpenCode Helper (Renderer): +2.31 s / 10 s (~23 %)
    • WindowServer: +3.83 s / 10 s (~38 %)
    • opencode-cli serve --service: +0.13 s / 10 s (~1 %)

    renderer.log for that same launch contains 17 occurrences of ResizeObserver loop completed with undelivered notifications in the first two minutes.

    Differences from the original report

    • No --use-gl=disabled here. The GPU helper is launched with only --type=gpu-process and --gpu-preferences=..., so software rendering does not appear to be required to reproduce the CPU burn.
    • Not an idle app in my case: a session was open and generating during sampling, so I cannot yet separate idle cost from streaming cost.
    • On a 10-core machine this stays under one full core, so it reads as battery and heat rather than system-wide lag. WindowServer is the largest single consumer.

    Ruled out

    • Session history size: measurements are identical before and after compacting the local session database from 3.0 GB to 1.0 GB.
    • Renderer JavaScript: a 3 s sample of the renderer shows the main thread parked in mach_msg2_trap, i.e. idle in JS, with the CPU going into compositing and paint instead.

    Related: #34289 (closed) describes the same renderer CPU association, but the symptom is still reproducible on 2.0.27.

  4. iqbal2746 commented on Oct 22, 2026

    @iqbal2746
    iqbal2746
    on Oct 22, 2026

    Additional data point: Windows 11, and a different conclusion about the cause.

    Environment

    • opencode Desktop 2.1.2 (bundled opencode-cli 2.1.2). Reproduced on 2.0.32 too — upgrading did not help.
    • OS: Windows 11, 10.0.26200.9711 (win32 x64)
    • CPU: AMD Ryzen 5 4600H, 6C/12T, 15.4 GB RAM
    • GPU: AMD Radeon Vega iGPU, driver 27.20.15002.11002 (2021-04-23) driving a 1920x1080 panel; NVIDIA GTX 1650 also present
    • Install/channel: release desktop app, per-user install, auto-updater reports up to date
    • Active plugins: none (no opencode.json/opencode.jsonc or .opencode config present)

    Measurements (10–15 s sampling windows, app idle, window unobscured)

    Configuration Total CPU (gpu-process + renderer)
    2.1.2, normal launch 243–294%
    Forced to discrete GPU (HKCU\...\DirectX\UserGpuPreferences, High performance) 243%
    --disable-gpu 231%
    --ignore-gpu-blocklist 294%
    Clean --user-data-dir (no user data) 274%
    --force-prefers-reduced-motion 0–1%

    Split when hot: gpu-process ~145–180%, renderer ~90–150%, opencode-cli serve --service ~5–31%. System-wide CPU load 76–87% on a 12-thread machine.

    What this rules out

    • Not user data. A clean --user-data-dir reproduces it (274%), so no session/database involvement.
    • Not GPU selection. Forcing the dGPU, disabling the GPU, and ignoring the GPU blocklist all leave it at 231–294%.
    • Not just software rendering. Software rendering makes each frame expensive (vk_swiftshader.dll is loaded in the gpu-process alongside atidxx64.dll), but turning GPU compositing off entirely does not reduce the burn.

    What it points at

    --force-prefers-reduced-motion drops it to 0–1% and fixes the machine. So the CPU is going into continuously re-rasterizing non-essential UI animation, not into the ResizeObserver error handling itself. The bundled stylesheet contains 81 distinct @keyframes (bang, blink, dash, dropdown-menu-open/close, composer-attachments-fade-*, …), several with animation: … infinite, and the app already contains ~26 prefers-reduced-motion references — it just doesn't reduce by default.

    Consistent with that: system "Animation effects" is already off on this machine (SPI_GETCLIENTAREAANIMATION = false) and the app ignores it.

    Why this is under-reported

    Task Manager shows the app at 1.8% CPU whenever its window is occluded behind another window, because Chromium stops painting when not visible. Bring it to the front and it immediately returns to ~240%. Anyone sampling with Task Manager maximized will see nothing wrong.

    Renderer log

    [error] ResizeObserver loop completed with undelivered notifications.
[warn]  [server-request-queue] server thrashing detected [object Object]
[info]  [global-sdk] event stream disconnected [object Object]

    214 ResizeObserver errors in a single ~3 h session, plus frequent event-stream reconnects.

    Suggested fix

    Gate infinite/looping animations on prefers-reduced-motion and on window visibility/idle state, and consider exposing a documented "disable UI animation" setting in the desktop app. Right now the only usable workaround is a command-line switch, which is lost on every auto-update.

  5. opencodejr commented on Oct 27, 2026

    @opencodejr
    opencodejrBot
    on Oct 27, 2026

    Thanks for the detailed measurements and logs!

    I think this is a duplicate of #55786. The --use-gl=disabled flag isn't set by OpenCode itself. It is Chromium falling back to software rendering because it couldn't start GPU rendering, and then the GPU helper uses about a full CPU core whenever the UI repaints. A MacBookAir7,2 is officially supported only up to macOS 12 Monterey, so Ventura 13.6 on it usually means OpenCore Legacy Patcher, the same setup as in #55786. The ResizeObserver loop errors are tracked in #52706. A repaint loop drawn by the software renderer would explain the high CPU even when the app is idle.

    Possible duplicates and related issues, ordered from most to least likely:

    The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different. For example, if you're not running macOS through OpenCore Legacy Patcher, please say so, because that would make this a separate case. Adding your data to #55786 and #52706 would also help.

  6. opencodejr
    added
    pending close
    triaging
    on Oct 27, 2026
  7. opencodejr
    closed this as duplicateon Oct 28, 2026

  8. opencodejr commented on Oct 28, 2026

    @opencodejr
    opencodejrBot
    on Oct 28, 2026

    We haven't heard back, so I'm closing this as a duplicate of #55786. That issue covers the GPU helper falling back to software rendering (--use-gl=disabled) on older Intel Macs and using about a full CPU core. The ResizeObserver loop errors in your renderer.log are tracked in #52706.

    Please follow those issues for updates. Your measurements from this 2-core MacBook Air would be useful on either one. If you're not running macOS through OpenCore Legacy Patcher, or your problem is different in some other way, reply here and we'll reopen this. Thanks again for the detailed report!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

pending closetriaging

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions