Repository navigation
Codex Desktop on macOS keeps GPU process and WindowServer at high CPU after long session #23026
Description
What happened
Codex Desktop on macOS appears to keep its Electron GPU/rendering pipeline busy after a long desktop session. The high usage does not look like local model inference; it is concentrated in the Codex Electron GPU process, the Codex renderer process, and macOS WindowServer.
Environment
- Codex Desktop version: 26.513.31313
- Electron version shown in process annotations: 42.0.1
- macOS: 26.4.1, build 25E253
- Architecture: arm64 / Apple Silicon
- Locale: zh-CN
- Session age at observation: about 11 hours
Observed resource usage
A process sample showed the following while the Codex window was open:
WindowServer ~42% - 46% CPU
Codex Helper --type=gpu-process ~28% - 34% CPU
Codex Helper (Renderer) ~18% - 24% CPU
codex app-server --analytics-default-enabled ~5% - 25% CPU
After waiting several seconds and sampling again, the usage was still high:
WindowServer ~44% CPU
Codex Helper --type=gpu-process ~28% CPU
Codex Helper (Renderer) ~18% CPU
codex app-server --analytics-default-enabled ~6% CPU
Other Electron/Chromium GPU processes on the machine were much lower at the time, so this appeared to be specific to the active Codex desktop window.
Steps to reproduce
- Open Codex Desktop on macOS.
- Use a long-running thread for several hours.
- Produce or view a large amount of streaming text / terminal output in the thread.
- Let the app stop actively responding.
- Check Activity Monitor or
psfor Codex GPU/renderer and WindowServer usage.
Expected behavior
Once Codex is no longer streaming or actively updating the UI, the Electron GPU process, renderer process, and WindowServer usage should return close to idle levels.
Actual behavior
The Codex GPU process and renderer process remain high, and WindowServer also stays high, suggesting continuous UI redraw/compositing work.
Notes
I did not see any local model inference process involved. The process pattern points to the desktop app rendering/compositing path rather than model execution.
Activity
github-actions commentedon May 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
felixblaschke commentedon May 17, 2026
Same here. Setting "Reduce Motion" to "On" helps a bit. To me it looks like those loading indicators are doing layout trashing in the UI, so whole layout / text needs be re-rendered every frame the indicator updates.
OpenSource03 commentedon Jul 30, 2026
Same. Hope for an update.
ToTorShi commentedon Aug 6, 2026
I reproduced the same issue on a newer Codex desktop build, with substantially higher CPU usage.
Environment
Timeline and observed usage
This was the first long-running app session after the app bundle updated. The app had been running for approximately 21 hours when the whole desktop became laggy.
Sustained measurements during the incident:
Closing WPS Office, DingTalk, and Xmind did not help. Quitting ChatGPT/Codex immediately restored normal responsiveness. After reopening it, system load fell to roughly 3–4 and the ChatGPT main process fell to about 2% CPU.
There were no thermal/performance warnings, almost no swap activity, sufficient free disk space, and no sustained disk I/O that explained the lag. Unified logs repeatedly contained MenuBarAgent/CoreAnimation handler failures, WindowServer invalid-window and window-constraint errors, cursor-surface failures, and client datagram-buffer clearing. No crash report was generated.
I have enabled an independent five-minute process monitor. If the issue recurs, I can provide a sanitized trend CSV and a pre-restart snapshot containing the most recent 15 minutes of relevant unified logs.
OpenSource03 commentedon Aug 7, 2026
I really hope more people recognize that this appears to be an interaction between Chromium and Apple’s WindowServer—not an issue specific to Codex or any one application. Windows and Linux don’t seem to be affected nearly as severely.
Even simple combinations like backdrop-filter: blur() and pulse animations can create excessive load on powerful Macs, reportedly including the M5 Max. Adding shimmer animations, such as those used for “thinking” states, can make it considerably worse. The same behavior can be reproduced on many complex websites containing animations, transparency, or backdrop blur.
I may be missing something, so please correct me if I’m wrong, but the evidence points primarily toward a macOS WindowServer/compositing problem, potentially amplified by Chromium’s rendering behavior or bug.
Even @t3dotgg made a video referencing similar problems, yet the broader role of WindowServer still seems largely overlooked. At the very least, even if all I just said is wrong, people should not need PhD in performance engineering to have simple pulse or shimmer animations working, as I can guarantee, people at Cursor, Anthropic, OpenAI or any other company will hardly ever care to put time and effort to diagnose these and find best possible solution, specially not JUST FOR MAC.
Really hope someone will investigate this at a lower level.