Codex Desktop on macOS causes sustained high CPU/GPU/WindowServer load and heating

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #23026
• #23072
• #23849

Powered by Codex Action

Solution: Codex #24185 — Desktop macOS High CPU/GPU/WindowServer Load

Issue: https://github.com/openai/codex/issues/24185
Labels: bug, app, performance
Competition: 1 comment (low competition)
Estimated Value: $1,000–$3,000
Created: 2026-05-23

---

Problem Summary

Codex Desktop (Electron 42.1.0) on macOS causes sustained high CPU/GPU/WindowServer load even when no heavy local task is running. The heat comes from the Electron UI layer, not the agent workload.

Observed CPU:

• WindowServer: ~41-46% CPU
• Codex Helper (GPU): ~24-35% CPU
• Codex Helper (Renderer): ~25-27% CPU
• Codex main process: ~0-3% CPU
• codex app-server: ~0-12% CPU

Workarounds tested (both ineffective):

• --force-prefers-reduced-motion — no material reduction
• --disable-gpu — attempted but likely incomplete

---

Root Cause Analysis

Hypothesis 1: Electron GPU Compositing Loop

The high CPU from Codex Helper (GPU) and Codex Helper (Renderer) indicates the Electron renderer process is stuck in a continuous GPU compositing loop. This happens when:

1. CSS animations running continuously: The UI has CSS animations (gradients, transitions, particle effects) that run even when the app is idle
2. RequestAnimationFrame loop: A JS requestAnimationFrame loop is running without a stop condition, causing the renderer to constantly repaint
3. Canvas/WebGL rendering: A canvas element is being redrawn every frame for visual effects (e.g., typing indicators, loading animations)

Hypothesis 2: WindowServer Interaction Issue

The high WindowServer CPU (41-46%) suggests the issue is not just internal to Electron but involves the macOS window server. This can happen when:

1. Frequent window compositing: The app is requesting window updates at a very high frequency
2. Shadow/border effects: macOS window shadows and borders are being recomputed frequently
3. HiDPI scaling: Electron's HiDPI scaling on macOS can cause excessive WindowServer load if the compositor is not properly throttled

Hypothesis 3: Electron 42.1.0 Specific Bug

Electron 42.1.0 is a very recent version. There may be a regression in the Chromium version it bundles that causes excessive GPU compositing on macOS.

Most Likely Root Cause

Primary: A requestAnimationFrame loop or CSS animation running continuously in the renderer process. The pattern is common in Electron apps with:

• Animated gradients or particle backgrounds
• Typing indicator animations
• Loading spinner animations that don't stop when idle
• Canvas-based visualizations

Secondary: Electron 42.1.0 may have a compositor bug on macOS that amplifies the issue.

---

Proposed Fix

Fix 1: Throttle requestAnimationFrame Loops

// src/renderer/components/animation-manager.ts

class AnimationManager {
  private rafId: number | null = null;
  private isIdle = false;
  private lastFrameTime = 0;
  private readonly MIN_FRAME_INTERVAL = 1000 / 30; // Cap at 30fps for idle animations
  
  startAnimation(callback: FrameCallback): void {
    if (this.rafId !== null) return; // Already running
    
    const frame = (timestamp: number) => {
      if (this.isIdle) {
        // Throttle to 1fps when idle

Thanks a lot for taking the time to write this up. I really appreciate the detailed analysis.

What you described matches what I’m seeing locally: app-server is mostly low, while Codex Helper (GPU), Codex Helper (Renderer), and WindowServer stay high. The duplicate issues also seem to show a similar pattern.

I’m not sure about the exact root cause, but your UI/rendering/compositing direction sounds very plausible. Thanks again for looking into this.

This is a really interesting breakdown 👀

What makes this report valuable is that the hot path seems heavily skewed toward persistent UI/runtime surfaces rather than active inference load.

The fact that:

• WindowServer stays hot
• GPU helper stays hot
• renderer stays hot
• app-server often sits near idle

…strongly suggests the expensive part may be “always-active desktop orchestration/render state” rather than actual model execution.

We’ve been seeing a similar pattern in long-running agent/runtime environments:
once a system keeps multiple realtime surfaces alive simultaneously (streaming state, thread hydration, diff rendering, attachment state, reconnect state, sidebar/session sync, etc.), the coordination overhead itself can become a persistent workload.

Especially when sessions become effectively “never fully cold” 🌡️

The interesting part is that reduced-motion didn’t materially help.
That makes this feel less like animation cost alone, and more like continuous compositing / invalidation / synchronization pressure somewhere in the desktop runtime stack.

Really solid diagnostics here ✨

Thanks, I appreciate the kind words and the thoughtful framing.

I also agree with the related reports that this should not be treated as a pure duplicate and closed away.

Across #23026, #23849, #22053, and this issue, the common pattern seems to be persistent desktop/runtime load rather than active model or tool execution. Reduced Motion may help slightly in some cases, but it does not appear to resolve the underlying issue.

The important signal is that multiple users are seeing Codex stay hot while app-server or actual task execution is mostly idle. I hope the team can treat these reports as a shared desktop runtime/compositing/synchronization bug family, not as isolated duplicates.

I can reproduce this on a newer Codex Desktop build, with Stage Manager disabled, so this does not look limited to the Stage Manager preview case.

Environment:

• Codex Desktop: 26.608.12217
• Helper framework version shown by process path: 149.0.7827.54
• macOS: 26.5.1 (25F80)
• Hardware: MacBook Pro with Apple M5 Max, built-in Liquid Retina XDR display
• Stage Manager: disabled (com.apple.WindowManager GloballyEnabled = 0)
• App signature/notarization: verified OK (spctl --assess --type execute --verbose=4 /Applications/Codex.app returns accepted, source Notarized Developer ID; Developer ID Application: OpenAI OpCo, LLC)

Observed after fully quitting and relaunching Codex Desktop, with no heavy local task running:

WindowServer                              ~42-51% CPU
Codex (Service) --type=gpu-process        ~15-35% CPU
Codex (Renderer)                          ~8-10% CPU
codex app-server                          usually low after relaunch, ~0-12% depending on moment

Before relaunching, the accumulated state was worse: Codex-related processes were around 12.6 GB RSS and roughly 129% aggregate sampled CPU, with many app-server/MCP/Computer Use helper children. After relaunch, this dropped to around 2.2 GB RSS and about 54% aggregate sampled CPU, but the GPU process and WindowServer still stayed unexpectedly hot.

A 5-second sample of the Codex GPU helper did not point to model inference or networking. The hot stack was concentrated in macOS rendering/compositing/color-management paths, including:

CA::Transaction::commit
CA::Context::commit_transaction
CA::Layer::commit_if_needed
CA::Render::Surface::Surface
CA::Render::Texture::encode
CA::Render::Encoder::encode_colorspace
IOSurfaceClientCopyValue
IOSurfaceClientSetPurgeable
CGColorSpaceCreateWithICCData
CGColorSpaceCopyPropertyList
ColorSyncProfileCreate
AppleCMMValidateProfile
ColorSyncProfileCopyData

The renderer sample also showed V8/Electron renderer activity, but the GPU helper sample being dominated by CoreAnimation / IOSurface / ColorSync makes this look like continuous compositor invalidation or surface/color-space churn rather than actual agent work.

Network latency was not the bottleneck in this run: proxied requests to api.openai.com / chatgpt.com were around 0.69s TTFB. Memory pressure was also not the trigger: no swap was in use.

This seems consistent with the broader family of reports in #23026, #23072, #23849, #26736, and this issue: Codex Desktop remains hot when the app UI is visible/active, while actual task execution is mostly idle. The important extra signal here is that it reproduces on a very high-end Apple Silicon machine and with Stage Manager disabled, so the trigger appears to be in the desktop UI/compositor path itself rather than a machine-capacity issue or Stage Manager-only interaction.