Codex App visible window causes sustained high GPU/WindowServer CPU and MacBook Air extreme heat

Open 💬 8 comments Opened Jun 28, 2026 by lewismoss

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.623.42026

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

The Codex macOS app makes my MacBook Air become very hot during normal use. I investigated this from within an active Codex session and found that the load is tied to the visible Codex desktop window, not to the CLI/app-server doing work.

Observed on macOS 26.5.1, Apple M4 MacBook Air, Codex App 26.623.42026.

While the Codex window was visible, process snapshots repeatedly showed high CPU in the Codex GPU/renderer path and WindowServer, for example:

WindowServer: ~39-54% CPU
Codex GPU process (Codex (Service) --type=gpu-process): ~35-42% CPU
Codex renderer: ~11-31% CPU
Codex app-server: usually low when not actively handling tool work

Sampling the hot processes showed the app-server mostly idle in Tokio/kevent/condition waits, while the hot GPU/renderer samples were in Chromium/Electron display/compositor paths and macOS graphics plumbing: CoreAnimation, IOSurface, ColorSync, Metal, AGX GPU driver calls, and compositor threads.

A hide/show test was especially clear:

Before hiding Codex: WindowServer ~45%, Codex GPU ~42%, Codex renderer ~31%
After hiding Codex with Cmd-H / setting the app invisible: WindowServer ~3.5%, Codex renderer ~0.6%, Codex GPU dropped out of the hot list
After restoring Codex: WindowServer ~39%, Codex GPU ~38%, renderer ~13%

So the issue appears to be a visible-window repaint/compositing loop in the Codex desktop app. The background agent/session can continue without the heat spike when the Codex window is hidden.

I initially suspected my external display because I sometimes use a 3840x1620 @ 180 Hz external monitor, but I can reproduce the same heating on the MacBook Air by itself with no external display connected.

What steps can reproduce the bug?

Open Codex App on macOS.
Start or resume a normal Codex chat/session.
Leave the Codex window visible while the session is active.
Watch Activity Monitor or run ps -axo pid,ppid,%cpu,%mem,rss,etime,command | sort -k3 -nr.
Observe sustained high CPU in WindowServer plus Codex GPU/renderer processes.
Hide the Codex app window.
Observe CPU drop sharply.
Restore/show the Codex app window.
Observe CPU rise again.

In my case, hiding the window reduced WindowServer from ~45% to ~3.5% and the Codex renderer from ~31% to ~0.6%. Restoring the window brought the load back immediately.

Profiling performed with sample showed the app-server was not the main source of work; the hot path was the visible UI/compositor/graphics path.

What is the expected behavior?

The Codex App window should not cause sustained high WindowServer/GPU/renderer CPU usage while visible during normal chat/session use. CPU/GPU activity should drop when the UI is idle, similar to what happens when the app is hidden.

Additional information

I checked for the syspolicyd pattern locally and did not see syspolicyd/trustd as the source of the load. I also checked thermal status with pmset -g therm; macOS had not recorded a thermal or performance warning at the time of testing, but the machine physically becomes hot during Codex use.

There were some stale/old Codex helper processes from previous sessions, but they were mostly idle and did not explain the high heat. The decisive signal was that hiding the visible Codex window immediately reduced WindowServer/Codex renderer/GPU load, and showing it brought the load back.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 2 months ago

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

#29374
#30021
#29281

Powered by Codex Action

larryisthere · 1 month ago

I’m seeing a very similar issue on macOS with Codex Desktop, and the impact has been significant.

This cost us several hours of investigation and a very large number of Codex tokens because the machine became so sluggish that even diagnosing the problem from inside Codex was slow and noisy. After correlating process snapshots, sample, and macOS system logs, the evidence points strongly to Codex Desktop as the trigger.

Observed behavior:

As soon as Codex Desktop is opened, the whole system becomes noticeably sluggish.
Quitting Codex Desktop makes the machine responsive again almost immediately.
This happens even after closing Chrome and disabling Handoff/Continuity.
The issue is tied to Codex Desktop. The CLI alone does not explain the user-visible slowdown.

Local evidence from Activity Monitor / ps / sample:

Codex (Renderer) spiked to ~85-90% CPU shortly after opening Codex Desktop.
WindowServer rose at the same time, observed around ~23-49% CPU.
Codex main process RSS reached roughly 1.2GB during the spike.
Codex (Service) --type=gpu-process also showed elevated CPU.
Codex app-server re-launched SkyComputerUseClient and node_repl subprocesses.

Sampling the hot renderer process showed the load inside Chromium/V8 renderer main-thread paths. Separately, system logs around the slowdown showed Codex Desktop UI/rendering related messages such as:

CoreAnimation Render fence tx observer ... timed out after 0.600000
HIRunLoop ... taking so long
AppKit layout recursion warning: layoutSubtreeIfNeeded ... already being laid out
StatusBar / BaseBoard scene failures during quit

The strongest user-visible signal is immediate: quitting Codex Desktop relieves the slowdown. Reopening Codex Desktop brings back renderer/GPU/WindowServer pressure. This matches the pattern described here: Codex Desktop visible/running drives renderer/GPU/WindowServer load, and the system recovers when Codex exits.

This should probably be treated as a high-impact Desktop performance regression, because it makes the entire Mac difficult to use and makes Codex itself difficult to use for diagnosing the problem.

larryisthere · 1 month ago

Additional Computer Use data point from the same macOS machine as my earlier comment.

After the earlier WindowServer/GPU slowdown report, I hit another severe system-wide slowdown that ended in a forced reboot. This time I had already closed the Codex Desktop window before the forced restart, but post-reboot diagnostics showed that Computer Use helper processes were still active in the user session.

Environment / timing:

macOS: 26.5.1 build 25F80, Apple Silicon
Forced reboot recorded at 2026-07-01 11:41:36 +0800
ResetCounter reported btn_rst,finger_reset force_off
The affected window was roughly 2026-07-01 10:20-11:42 +0800

WindowServer / HID symptoms during that window:

WindowServer timed_out_fence=320
WindowServer ping_timeouts=504
WindowServer event_enqueue_error=34
WindowServer event_enqueue_dropped=32
WindowServer cursor_disabled=103

Other concurrent pressure:

Spotlight/LaunchServices bundlefinder=12
LaunchServices failed_register=74
mds_xpc_timeout=4
spotlight_queries=1882
spotlight_stalling=38
cloudkit_requests=3968

Chrome also produced a disk-writes diagnostic at 2026-07-01 11:02, with about 2147 MB written over the sampled period, so Chrome/Spotlight/iCloud were also contributing pressure. However, the important Computer Use-specific finding is that closing the visible Codex Desktop window did not remove all Codex Computer Use processes.

Current-process check after reboot showed:

SkyComputerUseService: 1 process
SkyComputerUseClient event-stream mcp: 5 processes

The paths were under:

~/.codex/computer-use/Codex Computer Use.app

And the clients were launched as:

./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient event-stream mcp

This differs slightly from #29157, where the leaked helpers were turn-ended notifier helpers. In this later incident the residual helpers were event-stream mcp clients plus SkyComputerUseService. The user-visible failure was WindowServer/HID lag: dropped input events, render fence timeouts, cursor surface failures, and multiple clients failing WindowServer pings.

I removed the local Computer Use runtime and caches as a mitigation:

~/.codex/computer-use
~/.codex/plugins/cache/openai-bundled/computer-use
~/.codex/plugins/cache/openai-bundled/record-and-replay
~/Library/Preferences/com.openai.sky.CUAService*.plist
~/Library/Caches/com.openai.sky.CUAService*
~/Library/HTTPStorages/com.openai.sky.CUAService*
~/Library/Group Containers/2DC432GLL2.com.openai.sky.CUAService

After cleanup, pgrep no longer finds SkyComputerUseService, SkyComputerUseClient, CUAService, Computer Use, or record-and-replay processes, and filesystem search no longer finds Computer Use / SkyComputerUse / CUAService artifacts under ~/.codex or ~/Library.

Update: code-level cause identified and workaround validated

I investigated this further against the currently installed desktop build, 26.707.72221, on the same M4 MacBook Air.

The load is caused by the macOS desktop window’s rendering/compositing path. The shipped Electron bundle creates a focused primary window with a transparent background and native macOS vibrancy: "menu" unless the active theme has opaqueWindows: true.

While translucent, renderer layer updates are composited through Core Animation/IOSurface by the Codex GPU process and WindowServer. The bundle also has a large-window safeguard, but it only switches to opaque when both physical dimensions meet a 3840×2160 threshold. This does not account for high-refresh or ultrawide displays.

The existing Settings → General → Theme → Translucent sidebar option directly controls this behavior:

Translucent sidebar enabled → opaqueWindows: false
Translucent sidebar disabled → opaqueWindows: true

I disabled Translucent sidebar for both Light and Dark themes, enabled Reduce motion, quit, and reopened Codex.

Ten samples over 20 seconds while a turn was actively streaming showed:

| Process | Before | After mean | Reduction |
|---|---:|---:|---:|
| WindowServer | 83.9% | 7.87% | 90.6% |
| Codex GPU process | 34.4% | 2.38% | 93.1% |
| Active renderer | 12.7% | 2.93% | 76.9% |

A later instantaneous reading was WindowServer 1.0%, GPU 1.3%, and renderer 0.4%.

This is a clear step-change improvement and strongly validates the transparent/vibrant window as the dominant cause. The Rust app-server was not responsible.

Suggested product fix

Please make the primary macOS window use the existing opaque surface by default, leaving translucency as an explicit opt-in. At minimum, the opaque-surface decision should account for refresh rate/compositor cost instead of only the existing 3840×2160 size threshold.

Indefinite shimmer/streaming animations should also pause when not needed or when the document is hidden.

The relevant Electron desktop source does not appear to be included in the public openai/codex repository, so I cannot submit a directly buildable PR against it. The responsible logic was found in the shipped app.asar.

eartar93 · 23 days ago

Confirming the same issue on a newer Codex Desktop build, with a controlled renderer isolation test.

Environment

Codex Desktop 26.727.51351 (build 6119)
Bundled Codex Framework / Chromium 150.0.7871.182
macOS 15.7.4 (build 24G517)
MacBook Pro Mac16,7, Apple M4 Pro, 20-core GPU, 48 GB RAM
Internal 3456×2234 Retina display; no external display needed to reproduce

Observations

With Codex visible during ordinary use, hardware sampling showed approximately 65–77% overall GPU busy.
Activity Monitor attributed approximately 63–72% GPU to WindowServer and approximately 28% GPU to the Codex GPU service.
Restarting the Codex GPU helper did not resolve the condition.
Restarting the main renderer did not resolve it; the load returned with the replacement renderer.
Restarting Chrome's GPU helper did not materially affect the condition, and Chrome settled around 2% CPU.

Controlled isolation

Suspending only the active main Codex renderer with SIGSTOP reduced overall GPU busy from the 65–77% range to approximately 7.5%. Resuming/replacing the renderer caused GPU busy to return to approximately 77%.

This strongly isolates the active Codex renderer feeding the compositor/WindowServer path, rather than the Rust app-server or unrelated applications. It matches the continuous repaint/compositing behavior described in this issue.

Diagnostics and logs were uploaded privately through Codex /feedback.

Feedback ID: 019faf25-b610-7960-b385-e40adafcf317

1368584035-sketch · 8 days ago

Confirming this issue on a current Apple Silicon Mac mini.

Environment:

ChatGPT/Codex Desktop: 26.814.41407, build 6720
Embedded Chromium/Codex Framework: 151.0.7922.137
macOS: 26.6.2 (25G83)
Hardware: Mac mini, Apple M4, 16 GB RAM
Display: 3840 × 2160

The Mac remains cool during normal browsing and video editing with the same display configuration. The heating begins specifically when Codex starts working and decreases after Codex stops or exits.

I fully quit and relaunched ChatGPT/Codex, then left it idle for more than 10 minutes. The heating persisted.

A five-second process sample showed:

WindowServer: 25.6–26.1% CPU
Codex GPU service: 20.3–24.2% CPU
Main Codex Renderer: 8.6–11.4% CPU, approximately 600 MB RSS
codex app-server: approximately 0–1.5% CPU
Overall system CPU remained approximately 82% idle

No Vite, Next.js, test runner, ffmpeg, Python, TypeScript server, project Node server, or other local development workload was active. Disk activity and memory pressure were not the trigger. pmset -g therm reported no thermal or performance warning.

This strongly matches a visible Codex UI/GPU compositing or repaint loop rather than local agent execution, project scanning, display refresh rate, or another application.

Please investigate why the Chromium GPU process and renderer continue submitting sustained work to WindowServer when there is no corresponding local workload.

1368584035-sketch · 5 days ago

Update: the workaround identified by @lewismoss was very effective on my setup.

After disabling Translucent sidebar and restarting ChatGPT/Codex, the sustained heating has essentially disappeared. My M4 Mac mini now remains almost cool during normal Codex use, and the issue is resolved for me.

This confirms that switching the window to the opaque mode is an effective workaround on ChatGPT/Codex Desktop 26.814.41407 (build 6720), macOS 26.6.2.

Thank you very much for investigating the cause and documenting the workaround.

XXXym · 3 days ago

Confirming the same rendering/compositor pattern on a substantially newer desktop build.

Environment

ChatGPT/Codex Desktop: 26.818.41509 (build 6962)
macOS: 27.0 (26A5416b)
Hardware: MacBook Pro, Apple M3 Max (16 CPU cores), 64 GB RAM
App uptime when captured: about 2 days 8 hours

Observations

During an active Codex turn with the app visible, repeated one-second process snapshots showed:

WindowServer: 40.5%–43.2%
Codex GPU service (--type=gpu-process): 32.4%–42.5%
Long-lived Codex renderer: 17.6%–20.9%
Second Codex renderer: 8.5%–13.1%
codex app-server: usually near idle outside brief tool activity

A separate top interval captured WindowServer at 51.7%, the GPU service at 16.6%, and the renderers at 8.7% and 4.1%.

I then hid the entire ChatGPT/Codex app and waited 8 seconds before taking another interval sample:

WindowServer: 29.1%
Long-lived renderer: 0.0% (five earlier hidden snapshots measured 0.1%–1.5%)
GPU service: 23.6%
Second renderer: 10.3%

So hiding the app produced an immediate and repeatable drop in the main renderer and a meaningful reduction in WindowServer, although the GPU service and second renderer did not become fully idle while the agent turn was still active.

Process samples

A 3-second sample of the GPU process showed activity in VizCompositorThread, Metal command submission/completion queues, and AGX driver calls. Renderer samples contained Compositor and VideoFrameCompositor threads. The GPU process reported an 823.7 MB physical footprint with a 9.4 GB historical peak. The long-lived renderer was using roughly 1.4 GB RSS before the hide test.

System-wide memory pressure was healthy and the machine was about 82% CPU-idle at the start of diagnosis, so the load was concentrated in the visible desktop graphics path rather than a saturated machine or a local project workload.

This appears to reproduce the same visible-window compositor issue on 26.818.41509. I can provide the sample reports if useful.