Skip to content

High CPU use in idle on macOS (Desktop & cli) #26416

Closed as duplicate
Closed as duplicate

Description

@omergoktas

Description

Both Desktop and terminal apps consume high CPU while literally doing nothing in the background (not even the cursor is blinking, I clicked somewhere else just to test that).

Plugins

None

OpenCode version

1.14.41

Steps to reproduce

  1. Open the app
  2. Send a message to the AI agent (any message), and wait until it finishes up so that the IDE and the agent basically has nothing else left to do; idle.
  3. Watch the Activity Monitor for CPU use

Screenshot and/or share link

Image

Operating System

macOS 15.7.5

Terminal

macOS built-in terminal (no modifications whatsoever)

Activity

  1. github-actions commented on May 8, 2026

    @github-actions
    Contributor

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

  2. Epicism commented on Jun 5, 2026

    @Epicism

    Also experiencing this issue.

  3. viktor-ferenczi commented on Jun 26, 2026

    @viktor-ferenczi

    Same issue on Linux, suspect is rendering the damn progress indication with an embedded browser through a big DOM: #34045

  4. Astro-Han commented on Jul 14, 2026

    @Astro-Han

    I saw a related macOS CLI problem on OpenCode 1.17.20, with one useful distinction: my reproducible case was tied to the busy spinner, not a true idle loop.

    With animations enabled, the active TUI used 24-43% CPU. Disabling animations dropped the same process to 1-13%, and toggling them back on restored the high usage. Once no busy indicator was visible, CPU settled near 1%. Details and source links: #30086 (comment)

    If CPU remains high after the session status is fully idle, that is probably another path. The animation toggle is still a useful discriminator for this issue.

  5. sjursky commented on Aug 31, 2026

    @sjursky

    +1 on Linux (x86-64, Ubuntu 24.04.4 LTS), opencode v1.18.25. Reproduced the same idle high-CPU pattern.

    Symptom while the session is fully idle (no active request, no streaming, no file activity):

    • Main thread sits at ~50% of one core, STAT=Rl+ (running, not sleeping), WCHAN cycling through ep_poll.
    • The Bun HeapHelper thread sits at ~20-25% on futex — appears to be GC pressure driven by the main-loop churn.
    • No active network connections and no inotify event traffic at the time, so the spin is internal, not I/O-driven.

    This matches the epoll_pwait(..., timeout=0) busy-loop signature already reported in #24719 and #15600 — the runEventSubscription() reconnect loop in packages/opencode/src/acp/agent.ts with no backoff, and the broken-socket handling in http-server.ts / instance-events.ts. The main loop appears to poll with a zero timeout and immediately re-enters instead of blocking. The empty-string spin in MultiOccurrenceReplacer (packages/opencode/src/tool/edit.ts) is a related event-loop-blocking path.

    Killing and restarting the affected session is the only reliable workaround (consistent with #21889's findings). A proper fix would have the event loop block with a non-zero timeout / sleep when no events are pending, and add backoff to the reconnect path.

    Happy to provide more detail if useful. Would be great to know if a fix is planned for this, since it's been reported across several versions and platforms.

  6. neriousy commented on Oct 1, 2026

    @neriousy
    Member

    Closing as a duplicate of #19466, which tracks OpenCode using CPU while idle. Please add your platform and version there.

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