›_ Codex Issues
Codex Issues / #13749

Windows App causes elevated Desktop Window Manager (dwm.exe) GPU usage when visible on multi-monitor high-refresh setup

Open 💬 5 comments Opened Mar 6, 2026 by meAloex

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

26.305.950.0

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

When the Codex desktop app window is visible on screen, Desktop Window Manager (dwm.exe) GPU usage rises significantly on Windows.

On my system:

  • if Codex is visible, dwm.exe rises to roughly ~8-10% GPU (sometimes higher in Task Manager snapshots), and the Codex app also uses GPU

<img width="1101" height="423" alt="Image" src="https://github.com/user-attachments/assets/8035617d-3e30-47b4-90a0-203543dcea4f" />

  • if I minimize Codex (without closing it), both Codex GPU usage and dwm.exe GPU usage drop sharply, close to zero

<img width="1124" height="811" alt="Image" src="https://github.com/user-attachments/assets/cfc12742-86c3-4b1f-bece-9e78dbf2ee2f" />

This strongly suggests the problem is related to visible window rendering / composition rather than background work, network activity, or the process merely being open. All displays are now connected to the NVIDIA GPU, and this Codex-visible-window behavior still reproduces.

https://github.com/user-attachments/assets/da56a3d9-b6a9-42f8-84fd-7f5bb000b1e5

Sorry the clip is only ~5 seconds because of the 10 MB upload limit, but I hope it is enough to show how sharply GPU/DWM usage drops when Codex is minimized

What steps can reproduce the bug?

  1. Launch the Codex desktop app on Windows
  2. Keep Task Manager visible and sort by GPU usage
  3. Leave Codex open and visible on screen
  4. Observe that both Codex and Desktop Window Manager use noticeable GPU
  5. Minimize Codex without closing it
  6. Observe that GPU usage for both Codex and 'dwm.exe' drops sharply, close to zero

This appears to depend on the Codex window being visible rather than the app simply running in the background

What is the expected behavior?

_No response_

Additional information

System:

  • Laptop: Lenovo model 83F5 (Legion-class system)
  • Codex package: OpenAI.Codex_26.305.950.0_x64__2p2nqsd0c76g0
  • Windows: 25H2, build 26200.7840
  • NVIDIA GPU: GeForce RTX 5080 Laptop GPU
  • Driver: 32.0.15.9571
  • Driver date: 2026-02-27
  • Intel GPU: Intel(R) Graphics
  • Driver: 32.0.101.8243
  • Driver date: 2026-01-26

Display / graphics configuration:

  • All three displays are now connected to NVIDIA according to Windows Advanced Display
  • Internal panel: ATNA60HU01-0, 2560x1600 @ 240 Hz
  • External displays: 2560x1600 @ 144 Hz + 2560x1600 @ 144 Hz
  • Lenovo graphics mode: Discrete
  • Optimizations for windowed games: On
  • Variable refresh rate: On
  • Hardware-accelerated GPU scheduling: Off
  • MPO workaround had already been applied on this machine (OverlayTestMode=5)

View original on GitHub ↗

5 Comments

novovictus · 3 months ago

I built a small Windows/NVIDIA telemetry tool called WTG for this kind of debugging: figuring out whether a workload is really using the NVIDIA GPU, or whether Windows Task Manager is just not showing the relevant activity clearly.

Project page:
https://ninja-neer.net/

GitHub:
https://github.com/novovictus/WTG

Basic test:

.\wtg.exe --watch 250

Run that side-by-side with the workload and compare Task Manager, VRAM movement, GPU utilization, and power draw.

If Task Manager is flat but WTG shows VRAM/power/utilization movement, the GPU may be active and Task Manager may be misleading. If WTG is also flat, the workload probably is not reaching the NVIDIA GPU.

Happy to help interpret output if anyone posts a sample or emails [wtg@ninja-neer.net](mailto:wtg@ninja-neer.net).

0x000005 · 2 months ago

好像还会导致拖动所有窗口的时候有延迟

Howie654321 · 12 days ago

Additional reproducible data from a newer Windows build:

Environment

  • Windows 11 Pro, OS version 10.0.26200 (build 26200)
  • Codex MSIX 26.810.6296.0
  • Desktop host Chromium 151.0.7922.137
  • Measurements used Windows \GPU Engine(*)\Utilization Percentage counters at 1-second intervals. Each result is the maximum active engine per process for each sample.

Results

1. Codex visible with --disable-gpu

  • Flag confirmed on the root process; GPU child used d3d11-warp-webgl.
  • 10 samples: dwm.exe averaged 24.44%, peak 28.12%.
  • Codex GPU child averaged 3.20%, peak 4.64%.
  • Minimized: both averaged 0%, with effectively zero peak usage.

2. Codex visible with --disable-direct-composition

  • Flag confirmed on the root process and propagated to the GPU child; --disable-gpu and WARP were absent.
  • 10 samples: dwm.exe averaged 6.78%, peak 9.77%.
  • Codex GPU child averaged 0.76%, peak 1.36%.
  • Minimized: both averaged 0%, peak 0.01%.
  • Compared with the no-GPU/WARP run, DWM average was about 72% lower and peak was about 65% lower.

Interpretation

  • The visible-window dependency still reproduces in 26.810.6296.0: minimizing Codex eliminates both app and DWM GPU activity.
  • The commonly suggested --disable-gpu workaround made DWM load substantially worse on this machine by pushing rendering through WARP.
  • --disable-direct-composition was a more targeted mitigation and performed much better than WARP.
  • This was not a controlled comparison against an unmodified app run, so it should not be treated as proof of root cause or a general fix. It may nevertheless be a useful clue for investigating the Chromium/DirectComposition presentation path.
  • No registry, DWM, or MPO configuration changes were made during these tests.
Howie654321 · 12 days ago

Follow-up: attached is the PowerShell installer for the --disable-direct-composition workaround used in the measurements above.

  • Creates updater-aware Desktop and Start menu shortcuts for the current Codex MSIX package.
  • Does not modify the signed Codex package, Windows registry, or DWM settings.
  • Includes Install, Status, and Uninstall actions.
  • Installer script SHA-256: 4044F91DE463B2DF70537209F383D03E525E5567977D64F9396916941C613D1B

Attachment:

Codex-Dwm-Workaround-v2.zip

joshinacan · 23 hours ago

Additional reproducible datapoint from Codex 26.820.9563.0 on Windows:

Observed behavior

  • With the app visible and idle under a normal launch, dwm.exe accumulated 13.297 CPU-seconds over a 20-second sample.
  • Under the same visible-window condition, launching Codex with --disable-gpu reduced dwm.exe to 1.70 CPU-seconds over 20 seconds (about an 87% reduction).
  • The flag was verified on the root ChatGPT.exe process. Renderer processes carried --disable-gpu-compositing, while the GPU utility process reported --use-angle=d3d11-warp-webgl and --use-gl=angle.
  • In a separate 10-second DWM-Core trace, the ChatGPT GPU process was the dirty-generation source in 676 of 678 attributed events.
  • Sampled dwm.exe ETW stacks were dominated by dwmcore visual-tree cleanup, occlusion, and composition paths. NVIDIA driver code was a small part of the sampled stack (about 1.14% inclusive).

Controls

  • Setting all displays to 60 Hz did not remove the problem.
  • Windows Reduce motion = On did not remove it.
  • Minimizing the app sharply reduced DWM load.

Interpretation

This is more consistent with visible-window composition or presentation activity than with background agent work. On this machine, --disable-gpu is an effective mitigation. Another datapoint in this thread found worse DWM GPU utilization under WARP on different hardware, so the best mitigation may depend on the GPU/compositor path.

The trace establishes process attribution and the affected DWM paths, but it does not by itself prove the exact application-side invalidation source.