›_ Codex Issues
Codex Issues / #32024

macOS: visible Codex window drives WindowServer to 36–41% CPU on M4 MacBook Air

Open 💬 2 comments Opened Jul 10, 2026 by MichaelLin2001
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On an Apple M4 MacBook Air, opening the visible ChatGPT/Codex desktop window consistently drives WindowServer to sustained high CPU and makes the machine noticeably hot. Closing or hiding the window drops the load immediately.

This appears to be a visible-window rendering/compositing issue rather than agent execution, SSH, or a general macOS power setting.

Environment

  • Codex / ChatGPT desktop app: 26.707.31428 (build 5059)
  • macOS: 26.5.2 (25F84)
  • Hardware: Apple M4 MacBook Air, built-in 2560x1664 display only
  • No external display connected during the reproduction

Reproduction

  1. Start ChatGPT/Codex Desktop normally.
  2. Open a Codex task and leave the app window visible.
  3. Observe Activity Monitor.
  4. Hide or close the Codex window.
  5. Observe that WindowServer falls immediately; restore/show the window and it rises again.

Observed

With the window visible:

  • WindowServer: approximately 36% to 41.5% CPU
  • ChatGPT/Codex main process: approximately 10% to 12% CPU
  • Codex GPU service: approximately 4% to 6% CPU
  • Codex renderer: normally a few percent, with higher spikes while the task UI updates

When the ChatGPT/Codex window is closed/hidden, WindowServer drops to about 10% CPU. Opening the visible window brings it back to roughly 36% to 41%.

The issue persisted after fully restarting the app. A long, tool-output-heavy task increases renderer load further, but the visible blank/new task window still keeps WindowServer abnormally high.

Notes

  • Edge and the UU Remote user agent were closed/disabled during diagnosis; they were not the remaining cause.
  • syspolicyd was only around 3% to 5% and was not the primary source.
  • This matches the visible-window behavior described in #30464 and the foreground-heating report in #25036, but reproduces on the newer 26.707.31428 build.

Expected behavior

An idle or lightly used visible Codex Desktop window should not keep WindowServer, the GPU service, and renderer CPU high enough to heat a fanless MacBook Air.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #30464

Powered by Codex Action

BobH233 · 1 month ago

I can reproduce this issue on a newer Codex desktop build and different Apple Silicon hardware.

Environment

  • ChatGPT/Codex desktop app: 26.715.31251 (build 5538)
  • Chromium: 150.0.7871.124
  • macOS: 26.5.2 (25F84)
  • Hardware: MacBook Pro with Apple M3 Max, 40-core GPU
  • Displays initially connected:
  • Built-in 3456 × 2234 Liquid Retina XDR display
  • ASUS PA279, 3840 × 2160, rotated 90°, scaled to 1080 × 1920 at 60 Hz

Observed behavior

With the Codex desktop app open and visible:

  • Activity Monitor showed approximately 60% GPU usage attributed to WindowServer.
  • WindowServer remained at approximately 42–70% CPU during repeated samples.
  • The Codex Chromium GPU process reached approximately 20–22% CPU.
  • The main Codex renderer reached approximately 17% CPU.
  • The machine stayed under this load even when no intensive agent operation was running.

Closing the Codex desktop app caused GPU usage to return to normal immediately. Reopening the app caused the high WindowServer, Codex GPU, and renderer load to return.

Isolation performed

I initially suspected remote-desktop software and the external display, but neither was the primary cause:

  1. Fully closed the active RustDesk and ToDesk sessions.
  • WindowServer remained around 44–59% CPU.
  1. Physically disconnected the external ASUS display and waited for the display configuration to settle.
  • Only the built-in display remained online.
  • WindowServer still remained around 50–70% CPU.
  1. Closed the ChatGPT/Codex desktop app.
  • GPU usage immediately returned to normal.

This strongly points to the visible Codex desktop UI/compositor path rather than remote-desktop capture or the external display.

Relevant WindowServer logs

The following error was emitted continuously while Codex was open:

WindowServer: _CGXPackagesSetWindowConstraints: Invalid window

Additional diagnostics showed:

PKGWindowMoveOnMatchingDisplayChangedSeed failed to move window ... (invalid seed a0)

There were more than 14,000 related WindowServer errors, all emitted from the same WindowServer main thread. The error rate remained above 150 events per minute after disconnecting the external display.

This also appears closely related to #30464 and #32501.

The decisive signal is that closing Codex immediately restores normal GPU usage, while closing other GPU/screen-capture applications or disconnecting the external monitor does not.