›_ Codex Issues
Codex Issues / #18567

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

Resolved 💬 3 comments Opened Apr 19, 2026 by Liugouzi2023 Closed Apr 19, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

  • #18545

Powered by Codex Action

ybratec · 4 months ago

I am seeing a likely related rendering/compositor issue on an Intel Mac.

Environment:

  • Codex App: 26.422.30944 (CFBundleVersion 2080)
  • Electron: 41.2.0 (from the running crashpad process annotation)
  • macOS: 13.7.8 (22H730)
  • Darwin: 22.6.0 x86_64
  • CPU: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz

Observed behavior:

  • The Codex window intermittently turns fully gray, as if the current rendered window is hidden behind an opaque/translucent gray layer.
  • It can later render normally again and remain interactive, so it does not look like a hard app crash.
  • At the time I checked processes, Codex rendering processes were active: Codex Helper (Renderer) was using high CPU and Codex Helper GPU process was also active.

This feels consistent with a visible-window compositor/GPU path issue rather than model/session-specific behavior.

sakataka · 3 months ago

I can reproduce something very similar, but with Stage Manager already OFF.

In my case, the key finding was that ~/.codex/state_5.sqlite contained many threads.title values that were absurdly large (some over 200k chars). These were effectively full prompt bodies, not normal short chat titles.

After trimming those long threads.title values locally, Codex became responsive again.

So this may not only be a compositor / visible-window issue. There may also be a bug where very large first prompts get persisted into thread titles or related UI metadata, and the desktop app keeps reprocessing them.

Environment:

  • Codex Desktop 26.429.61741
  • Electron 41.2.0
  • macOS 26.4.1
  • Apple Silicon
  • External display connected
  • Stage Manager OFF