Repository navigation
[Windows][VS Code extension] System-wide UI stutter accumulates across sessions and clears only after sign-out #38793
Description
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
- Start from a fresh Windows sign-in with normal, smooth desktop performance.
- Open VS Code with Codex extension
openai.chatgptversion26.810.52044. - Run several coding-agent sessions over multiple hours.
- Finish all active agents.
- Observe progressively degraded system-wide window dragging and video rendering.
- Close every VS Code window and terminate remaining
Code.exe,codex.exe,codex-code-mode-host.exe, and associated helper processes. - Observe that system-wide lag persists.
- Press
Win+Ctrl+Shift+Bto reset the graphics driver. - Observe no improvement.
- Sign out of Windows and sign back in.
- 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_replhelper 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
- [Windows] System-wide stutter while Codex is idle; fully exiting app immediately restores OS responsiveness #38750 reports similar system-wide stutter, but for Codex Desktop and recovery occurs immediately after exiting the app.
- [Windows] Severe mouse stuttering after launching Codex Desktop until pet/avatar overlay is opened and closed #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.
Activity
github-actions commentedon Aug 15, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
zjbob commentedon Aug 15, 2026
I reviewed the potential duplicates. They appear related, but none is an exact duplicate of this report:
node_replworkers 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.The distinguishing recovery sequence here was:
Code.exe,codex.exe,codex-code-mode-host.exe, and associated helper processes: no improvement.Win+Ctrl+Shift+B: no improvement.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 commentedon Aug 22, 2026
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 commentedon Aug 23, 2026
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.
zjbob commentedon Aug 31, 2026
Checking in after the fix from #40672. I’m currently running VS Code extension
openai.chatgptversion26.825.51511and Codex CLI0.151.0-alpha.7.2, both newer than the version identified in #38844.Unfortunately, the original system-wide performance degradation remains reproducible. The fix for reusing private Windows desktops may have addressed one cause, but it does not appear to have fully resolved the behavior reported here.
I can provide fresh before/after DWM handle measurements or test a diagnostic build if that would help narrow down the remaining path.