Skip to content

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

Open
Open
Codex on macOS can drive high WindowServer CPU/GPU while idle when visible in Stage Manager preview#18545
Labels
appIssues related to the Codex desktop appbugSomething isn't workingperformance

Description

@tonyzhoup
tonyzhoup
opened on Apr 19, 2026

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

26.415.40636 (1799)

What subscription do you have?

Not sure

What platform is your computer?

macOS 26.3 (25D125) arm64

What issue are you seeing?

On macOS, Codex can drive very high WindowServer CPU/GPU usage even when I am not actively using the app, as long as Codex remains visible in Stage Manager's left-side live window preview.

This does not look like model execution or background task work. The heavy usage appears to come from the app's UI/rendering/compositing path interacting with Stage Manager's live preview.

In my case, shortly after restarting Codex and doing nothing in the app:

  • WindowServer was around 46% CPU and 24-30% GPU
  • Codex Helper --type=gpu-process was around 43% CPU
  • Codex Helper (Renderer) was around 29% CPU
  • two SkyComputerUseClient helper processes were present but mostly idle

Once I turned Stage Manager off and sent Codex to the background, WindowServer CPU/GPU dropped back down significantly.

What steps can reproduce the bug?

  1. On macOS, enable Stage Manager.
  2. Launch Codex desktop.
  3. Leave the app open, then switch to another app so Codex remains visible in the Stage Manager left-side preview column.
  4. Do not actively use Codex.
  5. Open Activity Monitor and observe WindowServer, Codex GPU/renderer helpers, and GPU usage.
  6. Turn Stage Manager off and keep Codex in the background.
  7. Observe that WindowServer CPU/GPU usage drops significantly.

What is the expected behavior?

When Codex is idle in the background, even if macOS Stage Manager keeps a live preview of the window, it should not continuously drive high WindowServer CPU/GPU usage.

Additional information

A few points that may help narrow this down:

  • This looks specifically like a render/compositing issue rather than remote inference or local agent execution.
  • Sampled stacks from the Codex GPU/renderer processes were dominated by symbols in the display/compositor path, including:
    • CA::Transaction::commit
    • CA::Layer::commit_if_needed
    • IOSurface
    • ColorSync
    • CVDisplayLink
    • VizCompositorThread
  • The SkyComputerUseClient helper processes appeared mostly blocked in mach_msg / idle waits, so they did not look like the main CPU source.
  • This suggests an interaction between:
    • Codex's idle UI redraw / compositing behavior, and
    • Stage Manager's live window preview rendering.

If useful, I can provide:

  • Activity Monitor screenshots
  • sample output from the Codex GPU and renderer processes
  • exact process snapshots from the affected state

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    on Apr 19, 2026

  2. github-actions commented on Apr 19, 2026

    @github-actions
    github-actionsbot
    on Apr 19, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. etraut-openai
    marked Codex Desktop on macOS keeps renderer/GPU active while visible, causing high WindowServer CPU and large memory footprint #18567 as a duplicate of this issue on Apr 19, 2026

  4. ayalshachar commented on May 3, 2026

    @ayalshachar
    ayalshachar
    on May 3, 2026

    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.

  5. etraut-openai
    added
    performance
    on May 3, 2026

  6. stlk0 commented on Jul 13, 2026

    @stlk0
    stlk0
    on Jul 13, 2026

    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.

  7. chrisbyan-dot commented on Jul 14, 2026

    @chrisbyan-dot
    chrisbyan-dot
    on Jul 14, 2026 – with ChatGPT Codex Connector

    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.

  8. wxyanwu commented on Jul 30, 2026

    @wxyanwu
    wxyanwu
    on Jul 30, 2026

    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.

  9. hongjieh commented on Aug 6, 2026

    @hongjieh
    hongjieh
    on Aug 6, 2026

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformance

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions