Codex Desktop on macOS keeps renderer/GPU active while visible, causing high WindowServer CPU and large memory footprint #18567

Summary

On macOS, Codex Desktop appears to keep its renderer/compositor pipeline active while the app window is visible but not frontmost. With only two chat threads open, this results in sustained WindowServer CPU usage, sustained Codex Helper (GPU) / Codex Helper (Renderer) activity, and a total Codex-related memory footprint around 1.6–1.7 GB.

This does not seem proportional to the current workload.

Environment

• App: Codex Desktop
• Version: 26.415.40636
• Build: 1799
• Electron: 41.2.0
• macOS: 26.3.2 (25D2150)
• Hardware: Apple Silicon Mac
• GPU: Apple M5 Pro, 16-core GPU

Observed behavior

Codex was:

• visible
• not frontmost
• not minimized

Even while not actively using the app, its rendering-related processes remained active.

Typical process activity observed

• WindowServer: 45%–69% CPU
• Codex Helper (GPU): 24%–33% CPU, ~142 MB RSS
• Codex Helper (Renderer): 16%–32% CPU, ~611–701 MB RSS
• Codex app-server: ~381 MB RSS
• Codex main process: ~391 MB RSS

Approximate total Codex-related memory footprint:

• ~1.6–1.7 GB

Minimize / restore validation

I compared process activity before minimizing the Codex window, after minimizing it, and after restoring it.

Before minimize:

• WindowServer: 47.2%
• Codex GPU: 28.6%
• Codex Renderer: 19.5%

After minimize:

• WindowServer: 25.0%
• Codex GPU: 0.0%
• Codex Renderer: 1.0%

After restore:

• WindowServer: 49.8%
• Codex GPU: 36.0%
• Codex Renderer: 24.5%

This strongly suggests the visible Codex window is continuously triggering rendering/compositing work even when not frontmost.

20-second sampling

I also sampled the related processes over ~20 seconds. The activity was sustained rather than a one-off spike:

• Codex GPU: mostly 24.7%–32.6%
• Codex Renderer: mostly 16%–32%
• WindowServer: mostly 45%–69%
• WeChat GPU: 0.0%
• VS Code GPU: 0.0%

So this did not look like another app was the primary source.

Sampling clues

Sampling the Codex renderer / GPU processes showed compositor/display-related activity including:

• VizCompositorThread
• CA::Transaction::commit()
• CA::Context::commit_transaction
• CA::Render::Surface::encode
• CVDisplayLink

This suggests the app continues participating in display refresh/compositing while visible.

Codex support files

I also checked ~/Library/Application Support/Codex/.

GPUCache, DawnWebGPUCache, and DawnGraphiteCache were open, but during a short observation window they did not appear to be the primary source of active churn. The only obvious file changes were to:

• sentry/scope_v3.json
• Cookies

So this currently looks more like a sustained rendering/compositing issue than heavy cache-write pressure.

Expected behavior

If Codex is visible but not actively used, renderer/GPU activity should drop significantly, or at least should not remain this high for such a light workload.

Actual behavior

Codex remains visually/compositionally active while merely visible, causing:

• sustained WindowServer load
• sustained renderer/GPU load
• disproportionately high memory footprint

Impact

• noticeable GPU / WindowServer spikes
• heavier-than-expected system load
• memory usage that feels too large for only two open threads