Repository navigation
[Windows app] System-wide mouse/input lag from repeated PowerShell WMI process snapshots #36025
Description
What version of the Codex App are you using (From "About Codex" dialog)?
26.721.11231.0 x64 (Microsoft Store package)
What subscription do you have?
Paid ChatGPT plan (exact tier omitted for privacy)
What platform is your computer?
Microsoft Windows NT 10.0.22000.0 x64
What issue are you seeing?
The Codex desktop app causes system-wide mouse pointer, dragging, and input latency on Windows. The lag begins approximately 10 seconds after opening the app and becomes more noticeable while a Codex task is running. The effect is not limited to the Codex window; interaction with other Windows applications is also delayed.
Live process observation shows that the desktop app repeatedly creates short-lived powershell.exe children which enumerate the full Windows process table through WMI. The observed commands include:
Get-CimInstance Win32_Process
Get-CimInstance Win32_PerfFormattedData_PerfProc_ProcessDuring an active task, the measured rate was approximately 1.2 to 1.3 new PowerShell children per second.
The current packaged JavaScript contains two relevant call paths:
- Electron performance sampling through
ElectronSampler.addChildProcessFields(). - Process management through
listProcessSubtrees(), including retry delays.
Windows WMI Activity Event 5858 was also observed for Win32_PerfFormattedData_PerfProc_Process, including an 0x800706BA result during one sample.
This machine has not reached the severe cleanup-storm state described in #34260:
taskkill.execount: 0conhost.execount during inspection: 5- WMI Event 5612 quota errors: 0
This appears to be the earlier repeated WMI polling stage, before any unbounded taskkill.exe or conhost.exe storm.
Temporarily changing the current Codex process tree to BelowNormal priority produced only a slight subjective improvement because it did not reduce the number of WMI queries and WmiPrvSE.exe runs outside the Codex process tree.
What steps can reproduce the bug?
- Fully exit the Codex desktop app.
- Start Codex 26.721.11231.0 on Windows x64.
- Wait approximately 10 seconds.
- Start or continue a task that performs local work.
- Move the mouse continuously, drag another application window, or type in another application.
- Observe intermittent system-wide pointer/input latency.
- Use process-start tracing or another non-WMI process monitor and observe repeated short-lived
powershell.exechildren launched byChatGPT.exe. - Inspect their command lines and observe repeated
Get-CimInstance Win32_ProcessandWin32_PerfFormattedData_PerfProc_Processqueries.
The issue reproduces after restarting Codex with its default process priority.
What is the expected behavior?
Codex should remain responsive without degrading system-wide mouse or input responsiveness.
Process telemetry and child-process cleanup should not launch a new PowerShell process and enumerate the full WMI process table approximately once per second. A native process API, cached snapshot, event-driven tracking, or a bounded/debounced sampler would avoid repeated WMI contention.
Additional information
A controlled, reversible A/B diagnostic was performed against the current process only. No application or system files were modified.
20-second transparent baseline
- Matching WMI snapshot calls: 24
- Aggregate
WmiPrvSECPU increase: 1.44 seconds - Errors introduced by instrumentation: 0
20-second suppression test
- The matching snapshot commands were temporarily replaced with a lightweight empty-result command.
- Aggregate
WmiPrvSECPU increase: 0.22 seconds - Reduction compared with baseline: approximately 85%
- However, calls increased to 77 because empty process snapshots triggered retry behavior.
Selective performance-snapshot suppression
- WMI CPU increase was reduced by approximately 33%.
- Calls still increased because an empty snapshot caused additional sampling/retry behavior.
These results support the WMI snapshot path as a major contributor to the lag, but returning an empty process tree is not a safe workaround. It can interfere with background-process discovery and cleanup and can amplify retries.
Related open issues:
- Windows Codex Desktop spawns powershell.exe every second for full process polling, causing high CPU usage #25453: repeated PowerShell full-process polling
- Codex triggers high CPU usage in WMI Provider Host on Windows after startup #29499: high CPU in WMI Provider Host after startup
- Windows 10: Codex background process causes intermittent system-wide mouse stutter #34158: system-wide mouse stutter
- Windows Desktop: unbounded taskkill.exe/conhost.exe cleanup storm exhausts WMI #34260: later-stage cleanup storm and WMI exhaustion
This is distinct from the serialport.node / Codex Micro crash tracked in #33518. There are no current 0xC06D007F crashes or current serialport.node errors on this installation.
Privacy note: account identifiers, task contents, session/thread identifiers, machine name, user paths, and raw logs have been intentionally omitted. Sanitized measurements or narrowly scoped event details can be provided if maintainers need them.
Activity
github-actions commentedon Jul 29, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
v2-share commentedon Jul 30, 2026
Thanks. I reviewed #34879, #35314, and #35827. This report is related, but it is not an exact duplicate:
taskkill.exestorm 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 [P0 regression] Windows desktop launch saturates all CPU cores via WmiPrvSE (26.715.10079.0) #34879.WmiPrvSECPU growth from 1.44 seconds to 0.22 seconds, while empty snapshots increased calls from 24 to 77 because of retries.Please keep this open or consolidate it into the canonical Windows WMI polling issue while preserving the current-version reproduction and A/B evidence.
InnovationLou commentedon Jul 30, 2026
Follow-up ETW/WPR results after additional controlled cleanup tests:
Environment
26.721.11231.0 x64(Microsoft Store/MSIX)Three controlled captures
Before archiving old tasks
git.exe, 159conhost.exe, 56taskkill.exeAfter archiving 68 old Codex tasks
git.exe, 122conhost.exe, 43taskkill.exeAfter removing all but one saved local Git project
git.exe, 104conhost.exe, 28powershell.exe, 26taskkill.exeWMI timing correlation
A direct timing test on the same machine produced:
Get-CimInstance Win32_Process: 117.6–157.1 msGet-CimInstance Win32_PerfFormattedData_PerfProc_Process: 404.7–437.3 msThat combined duration closely matches the repeated 0.49–0.64 second foreground stalls seen in ETW.
Inspection of the packaged app also shows:
child-process-snapshot-worker.jssampler-manageris constructed unconditionallyopenai/skills.git, contributing a separategit.exe/conhost.exeburstArchiving 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.
athan614 commentedon Jul 31, 2026
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.
v2-share commentedon Jul 31, 2026
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:
app.asarstill containsElectronSampler.addChildProcessFields(),listProcessSubtrees(), and theWin32_Process/Win32_PerfFormattedData_PerfProc_ProcessWMI snapshot path.[electron-sampler] Failed to collect child process snapshot.Win32_PerfFormattedData_PerfProc_Processwith result0x800706BA.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.
[-][Windows app 26.721.11231.0] System-wide mouse/input lag from repeated PowerShell WMI process snapshots[/-][+][Windows app] System-wide mouse/input lag from repeated PowerShell WMI process snapshots[/+]v2-share commentedon Aug 3, 2026
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:
[electron-sampler] Failed to collect child process snapshot.Get-CimInstance Win32_PerfFormattedData_PerfProc_ProcessandGet-CimInstance Win32_Process.Win32_PerfFormattedData_PerfProc_Processwith result0x800706BA.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.
chess-oai commentedon Aug 5, 2026
thanks for the detailed reports and investigation here: they were really helpful 💖
26.730.7989.0that address some major sources of powershell/wmi stormstaskkill.execan still be started by other process-cleanup paths, and we’re continuing to work on reducing that separatelyif you’re still seeing sustained wmi cpu usage or system-wide lag after
26.730.7989.0, please share an updated/feedbackidv2-share commentedon Aug 5, 2026
Follow-up validation after the WMI-related fixes shipped in the Microsoft Store app.
Current build
OpenAI.Codex 26.730.8199.0 x6426.730.7989.0build.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:
[electron-sampler] Failed to collect child process snapshotentry.Get-CimInstance Win32_ProcessorGet-CimInstance Win32_PerfFormattedData_PerfProc_Processsnapshot command recorded in the new startup log.taskkill.exe,conhost.exe, orgit.exeprocess storm.powershell.exeprocesses were observed during the 46-second startup window.WmiPrvSE.exesample 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 that26.730.7989.0shipped fixes for major PowerShell/WMI storm sources, with the current build containing those changes.DougieFresh8217 commentedon Aug 15, 2026
Fresh reproduction on a much newer Windows app build:
26.810.6296.0 x641.2026.190.0 x64Observed behavior:
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
/feedbackID can be supplied if needed. Please advise whether this issue should be reopened or tracked in a new canonical issue for current builds.