Codex on macOS can drive high WindowServer CPU/GPU while idle when visible in Stage Manager preview

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

• #16099

Powered by Codex Action

I’m seeing what looks like the same class of issue on an Intel MacBook Pro, with one extra data point: turning Stage Manager off did not materially fix it for me.

Environment:

• Codex Desktop: 26.429.30905 / build 2345
• Electron: 41.2.0
• macOS: 15.6.1 / 24G90
• Machine: MacBookPro16,1
• CPU: Intel i9-9880H
• GPUs: Intel UHD Graphics 630 + AMD Radeon Pro 5500M

Symptoms:

• Codex Desktop UI shows compositor-looking artifacts: ghosted UI elements and misplaced gradient/rectangle bands.
• While mostly idle/visible, Codex keeps sustained CPU in the GPU helper and renderer.
• The same project does not show this problem in the IDE extension.

Representative process snapshot while mostly idle:

Codex Helper --type=gpu-process: ~24-30% CPU
Codex Helper (Renderer): ~10-24% CPU
codex app-server: variable, often lower after startup
WindowServer: ~5-8% CPU

I temporarily disabled Stage Manager and restarted Dock:

defaults write com.apple.WindowManager GloballyEnabled -bool false
killall Dock

After confirming GloballyEnabled = 0, Codex still stayed elevated:

Codex Helper --type=gpu-process: ~25-29% CPU
Codex Helper (Renderer): ~10-15% CPU

I restored Stage Manager afterward.

I also took short sample captures of the hot Codex processes. The GPU helper sample showed activity in:

VizCompositorThread
CVDisplayLink
Metal
IOSurface
WebGPU
AppleIntelKBLGraphicsMTLDriver
com.Metal.CompletionQueueDispatch
com.Metal.CommandQueueDispatch

The app-server sample was mostly waiting on runtime/FSEvents/SQLite threads, so this looks more like visible-window rendering/compositing than project/model work.

Launch flag notes:

• --disable-gpu is not viable for me; it produced GPU access not allowed and left a runaway process at ~100% CPU.
• --disable-gpu-compositing launched but made the GPU helper worse in my test.
• --force_high_performance_gpu was inconclusive and did not look like a clean workaround.

So this seems related to the Stage Manager/live-preview issue described here, but at least on my Intel Mac it also reproduces with Stage Manager disabled.

I can confirm a closely related issue on an Intel MacBook Pro 16,1 (Core i9, Radeon Pro 5300M), running macOS 26.5.2 and ChatGPT/Codex Desktop 26.707.62119.
While the app window was active, macOS animations became choppy and keyboard input was noticeably delayed. WindowServer, the Electron renderer, and the GPU helper all showed sustained activity. Updating and restarting the app did not help.

Turning off Settings → Appearance → Translucent sidebar (Light&Dark theme) fixed the problem.

This suggests that the macOS vibrancy/translucency compositing path is responsible. It may be worth disabling translucency by default on affected Macs or investigating the vibrancy rendering path.

I can add a deterministic Apple Silicon A/B that appears to isolate the macOS translucency/vibrancy path, independent of Stage Manager.

Environment

• M2 MacBook Air, arm64
• macOS 26.5.2 (25F84)
• ChatGPT/Codex Desktop 26.707.71524, build 5263
• Stage Manager disabled (com.apple.WindowManager GloballyEnabled = 0)
• Lid closed; one external 21.5-inch LG UltraFine 4K active
• Display: native 4096x2304, logical 2048x1152 @ 60 Hz (exact 2x)
• Normal maximized Codex window: 2048x1029 logical / 4096x2058 physical

Measurement method

I sampled ioreg -a -r -c AGXDeviceUserClient twice per interval and calculated each process's accumulatedGPUTime delta divided by the 5-second wall-time. Values below are GPU-time rates, aggregated by IOUserClientCreator, not Activity Monitor CPU percentages.

| Condition | WindowServer | Codex GPU service | Combined |
|---|---:|---:|---:|
| Windowed, translucent sidebar enabled (2 checks) | ~64.7% | ~5.6% | ~70.3% |
| True full screen, translucent setting still enabled (3x 5 s average) | 19.69% | 6.45% | 26.14% |
| Windowed again, translucent sidebar disabled (3x 5 s average) | 20.19% | 5.61% | 25.81% |
| Minimized during the original translucent-window test | — | — | ~0.19% |

The three final windowed/opaque intervals were very stable: 25.92%, 25.88%, and 25.62% combined. A separate driver-level sample averaged 74.8% device utilization with the translucent window visible versus 22.7% in full screen.

Window-size clue

Static inspection of the shipped app bundle for this build shows that the macOS window surface appears to be forced opaque only when the physical window satisfies:

max(width, height) >= 3840 &&
min(width, height) >= 2160

Otherwise, a focused primary window uses vibrancy: menu unless the active theme explicitly enables opaque windows.

That creates a very specific boundary on this display:

• Normal maximized LG window: 4096x2058; short side is 102 physical pixels below the 2160 threshold, so it remains on the vibrant/translucent path.
• True full screen: 4096x2304; it crosses the threshold and GPU load drops immediately.
• Disabling Settings -> Appearance -> Translucent sidebar keeps the normal window opaque and preserves the same low-load behavior outside full screen.

For comparison, a normal window on a Studio Display was 5120x2634 physical and therefore already crossed the apparent opaque-surface threshold, which explains why the larger 5K display unexpectedly produced lower GPU load than this exact-2x 4K display.

Conclusion

For this machine, exact-2x HiDPI scaling is not the cause. The dominant delta is WindowServer composition associated with the Codex translucent/vibrant window surface. Disabling the translucent sidebar is a durable workaround and does not affect Codex functionality.

This complements the recent Intel report above and the earlier discussion in #10432. It may be worth:

1. defaulting to an opaque window on affected macOS configurations,
2. revisiting the hard 3840x2160 physical-window boundary, and
3. investigating why the vibrancy path continuously costs roughly 45 additional percentage points of WindowServer GPU time on this configuration.

I can reproduce the same WindowServer/compositor issue on another Apple Silicon Mac.

Environment

• Hardware: MacBook Air, Apple M4, 24 GB RAM
• Display: Built-in 2560 × 1664 Retina display only
• macOS: 27.0 (26A5388g)
• App: ChatGPT Desktop with embedded Codex
• Codex Framework: 150.0.7871.128
• CuaDriver: not running

Controlled A/B test

After rebooting, I measured WindowServer every 10 seconds for two minutes before opening ChatGPT/Codex:

• Average WindowServer CPU with ChatGPT/Codex closed: 3.4%
• Observed range: 2.2%–8.2%

I then opened ChatGPT/Codex and sampled the related processes again:

• Average WindowServer CPU: 39.2%
• Observed WindowServer range: 35.2%–42.8%
• Codex GPU process: approximately 7%–20% CPU
• Codex Renderer process: approximately 6%–13% CPU

This is an approximately 11.6× increase in WindowServer CPU immediately after opening ChatGPT/Codex.

The load remains elevated while idle. Restarting the app did not resolve it. Earlier process samples also showed compositor/display activity involving CVDisplayLink, QuartzCore/CoreAnimation, Metal, and SkyLight.

This strongly resembles the continuous renderer/compositor activity described in this issue.

I can reproduce a related rendering/compositing problem on macOS 26.3 (25D125) on an M1 MacBook Air, running the ChatGPT desktop app 26.730.61639 (build 6234) in Codex mode.

Observed on a single internal display:

• WindowServer sustained roughly 40–60% CPU after reboot.
• At capture time, ChatGPT/Codex was the dominant non-WindowServer graphics workload: its main/renderer/GPU helper processes were active, while Chrome, Deskflow, and Surge were comparatively low.
• Stage Manager was disabled, but the WindowServer activity persisted; restarting ChatGPT and rebooting did not eliminate it.
• A 10-second sample WindowServer capture showed repeated full-display compositing:

update_display_callback → CGXUpdateDisplay → WS::Updater::UpdateDisplays → SLCADisplay::render_update → CompositorMetal::CompositeLayersToDestination → CARenderOGLRenderDisplayWithOptions → CA::OGL::Renderer::render
with deeply repeated prepare_layers_roi, ImagingNode, and MaskNode calls.

This is strong evidence of sustained Core Animation/Metal layer compositing rather than model inference or an idle WindowServer loop. The WindowServer stack does not identify the responsible client by name, so I cannot prove attribution from this sample alone, but the simultaneous ChatGPT/Codex renderer activity makes it the likely trigger.

Is this considered the same compositor regression even with Stage Manager off? I can provide the full sanitized sample if it would help.