You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
High CPU use in idle on macOS (Desktop & cli) #26416
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
Open the app
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.
Watch the Activity Monitor for CPU use
Screenshot and/or share link
Operating System
macOS 15.7.5
Terminal
macOS built-in terminal (no modifications whatsoever)
Reacted by AstroHan, Gegham, Jens Lystad, Matteo Ricupero and Dorian Karter
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.
+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.
Activity
github-actions commentedon May 8, 2026
This issue might be a duplicate of existing issues. Please check:
Epicism commentedon Jun 5, 2026
Also experiencing this issue.
viktor-ferenczi commentedon Jun 26, 2026
Same issue on Linux, suspect is rendering the damn progress indication with an embedded browser through a big DOM: #34045
Astro-Han commentedon Jul 14, 2026
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.
sjursky commentedon Aug 31, 2026
+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):
STAT=Rl+(running, not sleeping), WCHAN cycling throughep_poll.HeapHelperthread sits at ~20-25% onfutex— appears to be GC pressure driven by the main-loop churn.This matches the
epoll_pwait(..., timeout=0)busy-loop signature already reported in #24719 and #15600 — therunEventSubscription()reconnect loop inpackages/opencode/src/acp/agent.tswith no backoff, and the broken-socket handling inhttp-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 inMultiOccurrenceReplacer(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.
neriousy commentedon Oct 1, 2026
Closing as a duplicate of #19466, which tracks OpenCode using CPU while idle. Please add your platform and version there.