›_ Codex Issues
Codex Issues / #38793

[Windows][VS Code extension] System-wide UI stutter accumulates across sessions and clears only after sign-out

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

What version of the Codex extension are you using?

  • VS Code extension identifier: openai.chatgpt
  • Extension version: 26.810.52044
  • Auto-update enabled; this was the current installed version during reproduction

What platform is your computer?

  • Windows display version 25H2, build 26200.9168
  • NVIDIA GeForce RTX 3070
  • NVIDIA driver 32.0.16.1088
  • Multiple monitors connected directly to the RTX 3070

What issue are you seeing?

After running several Codex coding-agent sessions through the VS Code extension for a few hours, the entire Windows interface becomes progressively laggy:

  • dragging windows becomes choppy
  • video playback renders poorly
  • the degradation increases with additional agent sessions
  • the lag remains after all agents finish
  • the lag remains after every VS Code/Codex process is closed
  • signing out of Windows and signing back in immediately restores smooth performance

This looks like a per-user-session graphical/resource retention problem triggered during sustained Codex extension use.

Steps to reproduce

  1. Start from a fresh Windows sign-in with normal, smooth desktop performance.
  2. Open VS Code with Codex extension openai.chatgpt version 26.810.52044.
  3. Run several coding-agent sessions over multiple hours.
  4. Finish all active agents.
  5. Observe progressively degraded system-wide window dragging and video rendering.
  6. Close every VS Code window and terminate remaining Code.exe, codex.exe, codex-code-mode-host.exe, and associated helper processes.
  7. Observe that system-wide lag persists.
  8. Press Win+Ctrl+Shift+B to reset the graphics driver.
  9. Observe no improvement.
  10. Sign out of Windows and sign back in.
  11. Observe that performance immediately returns to normal.

Resource measurements

During the affected session:

  • one long-lived codex.exe: approximately 809 MB RAM, 14,380 handles, 74 threads
  • approximately 15,000–16,000 handles across Codex processes
  • 22–25 node_repl helper processes were present, some several days old
  • Desktop Window Manager: approximately 304 MB RAM, 2,741 handles, 164 threads

After signing out and signing back in:

  • fresh Codex process: approximately 480 handles
  • Desktop Window Manager: approximately 115 MB RAM, 1,880 handles, 117 threads
  • desktop responsiveness was restored

Recent Windows event-log inspection found no nvlddmkm/display-driver timeout and no DWM application crash.

Expected behavior

Repeated Codex sessions should not progressively degrade system-wide graphics responsiveness. Codex and its helpers should keep resource usage bounded and release owned resources after tasks finish.

Recovery behavior / suspected scope

Closing all VS Code and Codex processes did not reverse the degradation, and resetting the graphics driver did not help. Signing out did help. This suggests resources or graphics state may remain retained by DWM or another per-user-session Windows component after the originating processes exit.

This does not establish the internal cause, but it makes permanent GPU degradation unlikely and points toward session-scoped resource retention.

Related issues

  • #38750 reports similar system-wide stutter, but for Codex Desktop and recovery occurs immediately after exiting the app.
  • #38745 reports severe Windows system/mouse stutter after launching Codex Desktop.

This report differs because the observed buildup followed sustained VS Code extension usage and persisted after VS Code/Codex exit; Windows sign-out was required to recover.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 12 days ago

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

  • #38537
  • #38714
  • #38754

Powered by Codex Action

zjbob · 12 days ago

I reviewed the potential duplicates. They appear related, but none is an exact duplicate of this report:

  • #38537 covers the VS Code extension leaking MCP server processes, but reproduces on macOS and focuses on retained child-process memory. This report adds Windows system-wide graphics degradation that persists after the originating processes are terminated.
  • #38714 covers retained node_repl workers and Windows UI stalls, but in the desktop app; fully exiting the app restores responsiveness. In this report, closing every VS Code/Codex process did not restore responsiveness.
  • #38754 covers Windows desktop stdio MCP/CUA overlay accumulation, where restarting Codex restores cursor smoothness. No Codex/VS Code restart or graphics-driver reset recovered this machine.

The distinguishing recovery sequence here was:

  1. Terminate all Code.exe, codex.exe, codex-code-mode-host.exe, and associated helper processes: no improvement.
  2. Reset the graphics driver with Win+Ctrl+Shift+B: no improvement.
  3. Sign out of Windows and sign back in: immediate full recovery.

DWM also dropped from approximately 304 MB / 2,741 handles / 164 threads in the affected session to approximately 115 MB / 1,880 handles / 117 threads after sign-in.

These issues may share an underlying worker/resource-lifecycle problem, but #38793 captures an additional downstream per-user-session/DWM state that survives process exit. I am therefore keeping it open unless maintainers prefer consolidation.

lonedfx · 5 days ago

This affects me too and has driven me crazy for over a month now. I investigated everything in my system trying to figure out what was causing it. Killing every single process does not fix it, until DWM itself is killed. I nearly reinstalled my whole Windows system over this.

I only finally found that Codex (which I run in the VsCode extension) is the culprit, after the bug mysteriously disappeared during a 4 day period when I did not use Codex at all. About 2h after using Codex again, the bug came back. I also use Claude in the VsCode extension, and it does not cause this issue.

This is a very serious problem, it poisons the entire Windows session to the point of making it entirely unusable after a few hours to a day tops. The evidence gathered by zjbob in the previous comment (regarding what does and does not recover the system and what look like DWM handle leaks) is 100% consistent with what I have found as well.

Please, PLEASE prioritize fixing this bug.

lonedfx · 4 days ago

I checked and this also happens with the CLI, not just with the VsCode extension. The issue is also consistent with issue 38844 above (2 handles leaked per shell command issued by Codex) though unlike that user, I am not using RDP, so live session vs RDP is not a factor.

I am on Windows 10 22H2 19045.7663, the video card is an NVIDIA GeForce RTX 2060. Driver is 610.74, but I recently updated that driver in an attempt to solve this issue, which it didn't, so it's not specific to this version of the drivers (if it's event related).

Interestingly my other machine which is a Windows 11 25H2 does NOT have this issue. However since the original reporter mentions they are running Windows 11 25H2 as well, it doesn't seem that this is Windows version-specific either.

A good way to see the issue in action is the following Powershell command:

while ($true) { "{0} {1}" -f (Get-Date -Format HH:mm:ss), (Get-Process dwm).Handles; Start-Sleep 1 }

Run this, and watch it climb every time Codex executes a shell command. A healthy DWM is in the low thousands of handles. After a few hours of intensive Codex use this rises beyond 10k. Somewhere between 10k and 20k, Windows becomes so slow that it's unbearable and I have to sign out and sign back in.