External Publication

Very high GPU usage when Codex is active window. REPORT.md and reproduction scripts included

OpenAI Developer Community June 29, 2026

Codex Desktop macOS GPU spike when focused

Summary

On macOS, the Codex Desktop app appears to trigger heavy sustained GPU/compositor activity whenever the Codex window is focused/frontmost. Switching focus to Chrome drops the GPU monitor to near idle immediately.

The effect reproduces with a small A/B script that focuses Chrome, samples powermetrics, then focuses Codex and samples again.

Environment

App: Codex Desktop
Bundle ID: com.openai.codex
Codex version: 26.623.61825 (CFBundleVersion 4548)
Chromium base: 149.0.7827.197
Machine: Mac15,10, Apple Silicon / arm64
macOS: 27.0 build 26A5368g
Kernel: Darwin 27.0.0

Quick reproduction

Open Chrome and Codex Desktop.
Run a focus A/B capture:

sudo powermetrics \
  --sample-rate 1000 \
  --sample-count 8 \
  --samplers tasks,gpu_power,cpu_power,thermal \
  --show-process-gpu \
  --show-process-energy \
  --output-file <output.txt>

Capture once with Chrome focused and once with Codex focused. In my local script, focus switching is done with osascript using bundle IDs com.google.Chrome and com.openai.codex.

Portable repro and logging script

The following script should run on any macOS machine with Codex installed in /Applications/Codex.app. It creates a timestamped folder containing:

metadata.txt: macOS, hardware, Codex version, current Codex process flags, thermal status, swap status.
Chrome-powermetrics.txt: raw baseline capture.
Codex-powermetrics.txt: raw target capture.
summary.txt: compact GPU active/power comparison to paste into an issue.

Usage:

chmod +x repro-codex-gpu-focus.sh
./repro-codex-gpu-focus.sh

If Chrome is not the desired baseline app, override the bundle ID:

BASELINE_APP_ID=com.apple.Safari BASELINE_LABEL=Safari ./repro-codex-gpu-focus.sh

repro-codex-gpu-focus.sh (click for more details)

Results

Launch mode	Focused app	GPU active avg	GPU active max	GPU power avg	GPU power max
Normal Codex launch	Chrome	`1.94%`	`2.92%`	`19 mW`	`26 mW`
Normal Codex launch	Codex	`70.16%`	`76.86%`	`2324 mW`	`3214 mW`
Reduced-GPU flags	Chrome	`1.70%`	`2.11%`	`15 mW`	`19 mW`
Reduced-GPU flags	Codex	`70.84%`	`78.59%`	`2644 mW`	`3404 mW`

Reduced-GPU test flags:

open -a "Codex" --args \
  --disable-zero-copy \
  --disable-gpu-memory-buffer-compositor-resources \
  --disable-accelerated-2d-canvas \
  --disable-accelerated-video-decode \
  --disable-features=CanvasOopRasterization

The reduced flags were visible in the Codex process command line, but did not reduce the GPU load. A harder launch using --disable-gpu --disable-gpu-compositing caused Codex to start without a visible window and required force quit, so that path was not usable.

Additional observations

pmset -g therm reported no thermal or performance warnings.
sysctl -n vm.swapusage reported 0.00M swap used.
powermetrics often attributes the sustained work to WindowServer rather than directly to Codex per-process GPU columns, but the focus A/B isolates the trigger to Codex being frontmost.
Other background CPU noise was present during some captures (fileproviderd, bird, cloudd), but it did not explain the GPU delta: Chrome focus stayed around 2% GPU active while Codex focus stayed around 70%.

Expected

An idle/focused Codex Desktop window should not sustain roughly 70% GPU active residency and 2.3-2.6 W GPU power when another Chromium/Electron-style app focus state is near idle.

Request

Please investigate whether the focused Codex Desktop window has a rendering/compositor loop or macOS WindowServer interaction that keeps the GPU active. I can provide the raw powermetrics captures if useful.