[Windows app] System-wide mouse/input lag from repeated PowerShell WMI process snapshots

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

• #34879
• #35314
• #35827

Powered by Codex Action

Thanks. I reviewed #34879, #35314, and #35827. This report is related, but it is not an exact duplicate:

• This reproduces on Windows x64 with Codex App 26.721.11231.0.
• No taskkill.exe storm or WMI Event 5612 quota errors were present, so this appears to be the earlier repeated process-snapshot stage rather than the later cleanup storm in #34879.
• The measured rate was approximately 1.2-1.3 short-lived PowerShell/WMI snapshot processes per second.
• A controlled 20-second A/B reduced aggregate WmiPrvSE CPU growth from 1.44 seconds to 0.22 seconds, while empty snapshots increased calls from 24 to 77 because of retries.
• #35827 observes the same PowerShell snapshot commands, but focuses on visible console flashes. This report focuses on system-wide mouse and input latency.

Please keep this open or consolidate it into the canonical Windows WMI polling issue while preserving the current-version reproduction and A/B evidence.

Follow-up ETW/WPR results after additional controlled cleanup tests:

Environment

• Codex App 26.721.11231.0 x64 (Microsoft Store/MSIX)
• Windows 11 Pro 25H2, build 26200.8875
• Intel i9-13900KS (32 logical processors), 32 GB RAM, NVIDIA RTX 4090

Three controlled captures

1. Before archiving old tasks

• 453 Codex-descendant process starts in about 13 seconds
• 166 git.exe, 159 conhost.exe, 56 taskkill.exe
• System CPU peaked at 75.56%
• Foreground UI/input delays: 219–735 ms

1. After archiving 68 old Codex tasks

• Descendant starts fell to 324
• 108 git.exe, 122 conhost.exe, 43 taskkill.exe
• Peak CPU fell to 49.64%
• Repeated UI stalls of 485–594 ms remained

1. After removing all but one saved local Git project

• 291 Codex descendants over about 50 seconds
• 85 git.exe, 104 conhost.exe, 28 powershell.exe, 26 taskkill.exe
• Repeated foreground delays: 547–641 ms
• The stalls still occurred when total non-idle CPU was only about 24%, so saturation alone does not explain them

WMI timing correlation

A direct timing test on the same machine produced:

• Get-CimInstance Win32_Process: 117.6–157.1 ms
• Get-CimInstance Win32_PerfFormattedData_PerfProc_Process: 404.7–437.3 ms
• Combined: about 0.52–0.59 seconds

That combined duration closely matches the repeated 0.49–0.64 second foreground stalls seen in ETW.

Inspection of the packaged app also shows:

• The two WMI queries are in child-process-snapshot-worker.js
• sampler-manager is constructed unconditionally
• Renderer-ready requests an immediate snapshot
• Heartbeat interval is 30 seconds; non-heartbeat minimum interval is 5 seconds
• Startup also synchronizes openai/skills.git, contributing a separate git.exe / conhost.exe burst

Archiving tasks and removing saved projects reduced the startup burst, but did not eliminate the WMI-correlated stalls. This suggests task/project refresh is a secondary amplifier, while the PowerShell/WMI snapshot path is the persistent cause.

Driver latency was ruled out in all captures: DPC/ISR events stayed at or below 1.024 ms (NVIDIA at or below 1.024 ms; USB at or below 0.512 ms).

Raw ETL files were removed after analysis because they contained local process/path metadata. Sanitized CSV-derived measurements can be provided if maintainers need them.

Same issue on my side, although WMI is no longer observed in task manager to be utilizing a very high percentage of CPU as of recently, severe system-wide stalls are still happening when codex is running tasks. It would cause every other program I have running (e.g. Google Chrome) to become unresponsive, and even the ChatGPT app itself. As a result of such, I am unable to use my computer at all when codex is running a task. Consequently, Codex also takes significantly longer to run scientific simulation tasks due to the system-wide stalls.

Follow-up after the Microsoft Store update on 2026-07-31.

I installed the latest Microsoft Store package today. The installed version is now OpenAI.Codex 26.727.4816.0 x64, but the system-wide mouse and input lag is still present.

Fresh post-update evidence:

• The shipped app.asar still contains ElectronSampler.addChildProcessFields(), listProcessSubtrees(), and the Win32_Process / Win32_PerfFormattedData_PerfProc_Process WMI snapshot path.
• A same-day post-update session logged [electron-sampler] Failed to collect child process snapshot.
• Windows WMI Activity Event 5858 was recorded for Win32_PerfFormattedData_PerfProc_Process with result 0x800706BA.

This indicates that the package version changed, but the WMI process-snapshot path associated with this issue is still present and still producing the same failure signature.

A controlled fresh launch was also performed without starting a task, so I am not presenting that launch alone as a new task-time reproduction. No application files, registry settings, WMI services, or process-priority settings were modified during this check.

Please verify whether this sampler/process-tree implementation has changed in a later build and consider replacing the repeated full WMI enumerations with a native, cached, event-driven, or bounded approach.

Validation on the latest Microsoft Store build: OpenAI.Codex 26.727.6591.0 x64 (2026-08-03).

I performed a clean app startup with no active task started. No application files, registry settings, WMI services, or process-priority settings were modified.

The same WMI sampler failure signature is still present:

• About 13 seconds after launch, the desktop log recorded [electron-sampler] Failed to collect child process snapshot.
• The failed snapshot command included both Get-CimInstance Win32_PerfFormattedData_PerfProc_Process and Get-CimInstance Win32_Process.
• About 3 seconds later, Windows WMI Activity Event 5858 recorded Win32_PerfFormattedData_PerfProc_Process with result 0x800706BA.

This is a fresh dynamic reproduction of the sampler/WMI failure signature on 26.727.6591.0, not merely a static package-string check. No task was deliberately started during this validation, so it confirms that the startup sampler path persists but does not claim a new task-time process rate or an end-to-end input-latency measurement.

The user still observes system-wide mouse/input lag in normal use after the update. Please keep this issue open and investigate the repeated PowerShell/WMI process-snapshot path in the current Store build.

thanks for the detailed reports and investigation here: they were really helpful 💖

• we’ve shipped fixes in 26.730.7989.0 that address some major sources of powershell/wmi storms
• taskkill.exe can still be started by other process-cleanup paths, and we’re continuing to work on reducing that separately

if you’re still seeing sustained wmi cpu usage or system-wide lag after 26.730.7989.0, please share an updated /feedback id

Follow-up validation after the WMI-related fixes shipped in the Microsoft Store app.

Current build

• Store package: OpenAI.Codex 26.730.8199.0 x64
• This build was installed on 2026-08-05 after the previous 26.730.7989.0 build.
• The Microsoft Store currently reports no newer package.

Validation scope

This follow-up intentionally checks only the PowerShell/WMI process-snapshot storm tracked by this issue. It does not combine the separate conversation-switching UI latency observed after the WMI storm was reduced.

A clean startup was monitored for approximately 46 seconds. No task was started during this capture.

Results

The previous WMI storm signature was not observed in the current build:

• No [electron-sampler] Failed to collect child process snapshot entry.
• No WMI Activity Event 5858 during the startup capture.
• No Get-CimInstance Win32_Process or Get-CimInstance Win32_PerfFormattedData_PerfProc_Process snapshot command recorded in the new startup log.
• No taskkill.exe, conhost.exe, or git.exe process storm.
• Only 2 new powershell.exe processes were observed during the 46-second startup window.
• A 20-second WmiPrvSE.exe sample showed a maximum CPU increase of approximately 0.062 seconds, with no sustained growth.

These results indicate that the major repeated PowerShell/WMI storm described in this issue is no longer reproduced during clean startup on 26.730.8199.0. This is consistent with the developer statement that 26.730.7989.0 shipped fixes for major PowerShell/WMI storm sources, with the current build containing those changes.

Fresh reproduction on a much newer Windows app build:

• Codex app: 26.810.6296.0 x64
• ChatGPT Desktop also installed: 1.2026.190.0 x64
• Windows 11 desktop
• Ryzen 7 2700X, RTX 5080 16 GB, 48 GB RAM
• Three-display setup, including a 7680x2160 Samsung Odyssey G95NC at 120 Hz

Observed behavior:

• The system can remain completely smooth during gaming, ComfyUI image generation, and an extended voice-only ChatGPT session.
• After active Codex task/tool work, the mouse pointer and dragged windows intermittently become severely choppy system-wide, with large visible gaps in pointer movement.
• The rest of the system remains responsive; this does not correlate with RAM, GPU, CPU, or disk exhaustion.
• Ending the complete grouped ChatGPT/Codex process tree in Task Manager stopped the stutter immediately.
• After reopening Codex, the system remained smooth for a while, then the same stutter returned following further active use.
• Restarting the graphics driver with Win+Ctrl+Shift+B did not help.
• Moving the wired mouse to another direct USB port did not help.
• In one affected-state Task Manager snapshot, the ChatGPT process group showed about 10% CPU and 1.56 GB RAM, without overall system saturation.

This is a repeatable app-running-versus-fully-terminated A/B result on a build substantially newer than 26.730.7989.0. The earlier startup WMI storm may be fixed, but a remaining task/tool-activity or process-cleanup path appears capable of producing the same system-wide input symptoms.

A fresh in-app /feedback ID can be supplied if needed. Please advise whether this issue should be reopened or tracked in a new canonical issue for current builds.