Codex triggers high CPU usage in WMI Provider Host on Windows after startup

Thanks for writing this up. I am seeing a related Windows Codex Desktop performance regression in #28855: since June 12, opening/using Codex Desktop can cause severe intermittent mouse/typing/system input lag, and it still persists for me on OpenAI.Codex 26.616.10790.0.

I linked your report in a broader Discussion collecting recent Windows Desktop performance reports here: https://github.com/openai/codex/discussions/29949#discussioncomment-17428007

No action needed from you unless you want to add more detail there, but I wanted to connect the reports because the recent Windows issues look related enough that they may need a canonical tracker.

I have a lower-level confirmation from an affected machine that may help narrow this issue. This reproduces on Codex desktop 26.707.8479.0, Windows 11 25H2 build 26200.8737, immediately after a clean reboot.

Signed Microsoft WMI-Collect trace

I ran Microsoft's signed WMI-Collect/TSS collector with WMI Activity, RPC, provider-performance, and kernel-process tracing while Codex was actively streaming an agent turn.

In a 52.18-second trace:

• The kernel logger recorded 24 powershell.exe starts directly parented by the Codex desktop main process: 27.6/minute.
• All 24 became WMI clients.
• One additional Codex PowerShell/WMI pair began just before the kernel logger started and appears in the WMI trace.
• Those Codex-parented clients generated 111 WMI operation events:
• 74 IWbemServices::Connect
• 13 broad Win32_PerfFormattedData_PerfProc_Process censuses
• 13 broad Win32_Process censuses
• 11 filtered Win32_Process detail queries

All operations succeeded on the fresh boot, but the broad calls were already expensive:

| Operation | Count | Median | Maximum |
| --- | ---: | ---: | ---: |
| Win32_PerfFormattedData_PerfProc_Process census | 14 | 467.95 ms | 480.15 ms |
| Broad Win32_Process census | 14 | 198.58 ms | 222.46 ms |
| Filtered Win32_Process detail | 13 | 205.91 ms | 213.26 ms |

The CIMWin32 provider host reached 48.63% CPU during the trace. The collector completed without script errors and reported a healthy/consistent WMI repository, default provider quotas, no quota violations, default WMI permissions, and default DCOM/RPC settings.

Installed-package analysis

Read-only inspection of the signed package found:

• Renderer streaming deltas request an electron-app-state-snapshot-trigger through a 5-second deltaBurstEmitGate.
• Agent/reasoning/plan/command/file deltas plus thread/turn lifecycle events can trigger snapshots.
• The main process has a 5-second non-heartbeat gate and 30-second focused heartbeat, but no snapshot single-flight/coalescing or failure backoff.
• Performance-span enrichment calls the host collector directly and bypasses the 5-second trigger gate.
• Each Windows host snapshot creates a worker that launches PowerShell for a broad Win32_Process census, then another PowerShell path for the broad formatted performance class plus selected process details.
• Statsig gate 2533914996 controls performance-span sampling only; no supported full Windows host-sampler override was found.

Kernel retention / severity

On a prior 25.8-hour boot, the independent native pool recorder reached:

Toke  1,236,319 outstanding  2,294,308,096 bytes
SeTd  1,236,319 outstanding    178,022,944 bytes
SeAt  4,952,348 outstanding    475,753,664 bytes

A targeted kernel ETW capture with symbols resolved sampled outstanding Toke allocations through:

ExAllocatePoolWithTag -> ObCreateObjectEx -> SepDuplicateToken -> SepCreateClientSecurityEx -> SeCreateClientSecurity -> NtAlpcCreateSecurityContext/AlpcpCreateClientPort -> rpcrt4/combase -> fastprox/wbemcore

The degraded session ended in an unrecovered whole-system hard hang. The final Codex child-process snapshot timed out at the same boundary where all machine telemetry stopped. There was no bugcheck or dump from that incident, so I am treating Codex as a proven high-rate trigger/amplifier, not claiming it is yet the uniquely proven owner of the final Windows retention/deadlock.

Requested containment/fix

Could OpenAI:

1. Remotely disable gate 2533914996 for the affected account as partial emergency containment.
2. Provide a supported switch that disables all Windows host child-process sampling.
3. Replace per-snapshot PowerShell/WMI census work with a persistent native process collector.
4. Make collection single-flight, cached, rate-bounded, and protected by timeout backoff/circuit breaking.

Blocking PowerShell, disabling WMI, patching the signed MSIX, or editing feature caches are not acceptable local mitigations.

I have a sanitized 26 KB evidence bundle ready. The raw Microsoft WMI ETL (864 MB), kernel ETL, provider dumps, and event logs are retained locally and can be transferred through a private maintainer channel.

I can independently confirm that this is still reproducible on a substantially newer Windows Desktop build, and in the affected state the impact can be much worse than a brief startup spike.

Environment

• Codex Desktop MSIX: OpenAI.Codex_26.715.2305.0_x64
• OS: Windows 11 x64
• CPU: AMD Ryzen 9 9950X3D
• Date reproduced: 2026-07-17
• WSL was not involved in the reproduction

User-visible impact

The problem is intermittent. Some launches remain normal, but when it triggers:

• total CPU utilization rises to approximately 99%;
• WmiPrvSE.exe / WMI Provider Host consumes the resources;
• the machine becomes severely degraded even though Codex is not doing useful local compute;
• closing/restarting the app may temporarily change the behavior, but the sampler failures return.

This is especially concerning on a 9950X3D: the result cannot reasonably be explained by a low-end machine or ordinary application startup work.

WMI Activity evidence

At 2026-07-17 15:59 JST, Microsoft-Windows-WMI-Activity/Operational recorded a burst of Event ID 5858 entries. One representative event was:

ClientProcessId = 471636
Operation = Start IWbemServices::ExecQuery - root\cimv2:
SELECT __PATH, ProcessId, CSName, Caption, SessionId, ThreadCount,
       WorkingSetSize, KernelModeTime, UserModeTime, ParentProcessId
FROM Win32_Process
ResultCode = 0x80041032

The client PIDs are short-lived. Additional events from the same failure pattern used 0x800706BA and reported that WMI could not send status back to the client.

Exact correlation with Codex logs

The local Codex desktop log at the same instant contains:

2026-07-17T06:59:02.739Z warning [electron-sampler]
Failed to collect child process snapshot
Command failed: powershell.exe -NoProfile -NonInteractive -Command ...
Get-CimInstance Win32_Process |
  Select-Object ProcessId,ParentProcessId |
  ConvertTo-Json -Depth 2

The warning repeated at approximately:

06:58:03.502Z
06:58:33.161Z
06:59:02.739Z
06:59:33.003Z
07:00:04.590Z
07:00:33.678Z
07:01:02.415Z
07:01:33.015Z
07:02:09.825Z
07:02:33.135Z

After another Codex restart, a new log recorded seven more [electron-sampler] Failed to collect child process snapshot warnings between 07:13:16Z and 07:17:14Z.

The commands recorded by Codex include both expensive paths already reported in this issue:

Get-CimInstance Win32_Process
Get-CimInstance Win32_PerfFormattedData_PerfProc_Process

The second path builds a global CPU map and then queries a large OR filter containing many descendant PIDs. The stack points into the packaged desktop host:

app.asar\.vite\build\main-FGp_fjyX.js
Worker: child-process-snapshot-worker.js
Logger: electron-sampler

Read-only inspection of the installed package also confirms a focused-window heartbeat of roughly 30 seconds plus additional snapshot triggers. There is no supported user-facing switch that disables the complete Windows host sampler.

Why the intermittent nature does not reduce severity

The regular heartbeat and activity-triggered snapshots do not always overlap or fail. When WMI is responsive, the user may only see a short spike. When probes become slow, overlap, are cancelled, or repeatedly lose their client, the same implementation can turn into an Event 5858 storm and drive WMI Provider Host to saturation.

Requested containment

Could OpenAI please provide a public engineering status and ship an immediate containment while the native collector is being redesigned?

At minimum:

1. make Windows snapshots single-flight and coalesced;
2. add timeout backoff / a circuit breaker after repeated WMI failures;
3. stop global Win32_PerfFormattedData_PerfProc_Process enumeration;
4. provide a supported switch to disable all host process sampling;
5. stop or heavily throttle sampling when the app is idle or backgrounded.

This reproduction appears to be the same defect family as #22912, #25453, and #32562. The important new data point is that it is still present in 26.715.2305.0 and can saturate a Ryzen 9 9950X3D system. A screenshot of the Event 5858 burst and the matching local logs are available if maintainers want them through a private channel.

Independent field confirmation with a long-running active Codex task. This appears to be the same defect family as #25453, but the long-duration failure mode is substantially more severe than a short startup spike.

Environment

• Codex Desktop MSIX: OpenAI.Codex_26.715.2305.0_x64
• Windows 11 x64: 10.0.26200.8875
• CPU: AMD Ryzen 9 7945HX (16C/32T)
• Workload: one Codex agent task actively making real progress for approximately 5 hours
• The task did not show an obvious retry/agent loop and was not stopped during diagnosis

User-visible impact

For most of the five-hour run:

• Task Manager showed roughly 200 background processes (temporarily falling to 120+ later).
• Total CPU remained at approximately 100% for several hours.
• WmiPrvSE.exe / WMI Provider Host was a dominant consumer; one captured sample showed a single WMI Provider Host at 52.4%.
• The entire machine became severely unresponsive. Even mouse movement stuttered badly.
• This saturated a Ryzen 9 7945HX, so this is not ordinary workload pressure on a low-end CPU.

Direct parent/command-line evidence

A native process-start capture (avoiding WMI for the capture itself) showed the packaged Codex Desktop ChatGPT.exe parent repeatedly starting short-lived powershell.exe children every approximately 2-3 seconds.

Captured commands included:

powershell.exe -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId | ConvertTo-Json -Depth 2"

and:

powershell.exe -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; $cpuByPid = @{}; Get-CimInstance Win32_PerfFormattedData_PerfProc_Process | ForEach-Object { $cpuByPid[[int]$_.IDProcess] = [double]$_.PercentProcessorTime }; Get-CimInstance Win32_Process ... | Select-Object ProcessId,ParentProcessId,CommandLine,WorkingSetSize,... | ConvertTo-Json -Depth 2"

WMI Activity evidence

From Microsoft-Windows-WMI-Activity/Operational, during a 51-minute window:

• Event ID 5858 entries: 1,047
• Unique WMI client PIDs: 977
• Almost all operations were Win32_Process enumeration/query operations.
• Busiest minute: 74 events from 70 unique client PIDs
• Observed result codes included 0x80041032 and 0x800706BA ("Could not send status to client").

This strongly indicates high short-lived client-process churn, not one persistent WMI client.

Backpressure/overlap evidence

In the degraded state, a single native tasklist process snapshot took approximately 21.8 seconds to complete.

At the same time, Codex's process sampler continued creating new PowerShell/WMI clients at a much shorter interval. This creates a positive-feedback failure mode:

long-running tool/turn
-> process snapshot trigger
-> global WMI census becomes slow
-> next snapshot starts before earlier work has cleared
-> short-lived clients fail/exit
-> Event 5858 storm and WmiPrvSE saturation
-> process enumeration becomes even slower

After the CPU storm temporarily subsided, a 16-second native performance-counter sample showed:

• Process count oscillating between 374 and 380
• Thread count oscillating between 14,448 and 14,550
• No monotonic growth during that window

So this does not look primarily like hundreds of permanently unreaped conhost.exe or PowerShell processes. It looks like a process churn / overlapping sampler / missing backpressure problem. The transient processes are generally reaped, but their creation and global WMI work can consume the whole machine.

No Codex, WMI, PowerShell, console, or task process was terminated during this diagnosis; the five-hour task was allowed to continue.

Requested fix / containment

Please treat this as a high-severity system responsiveness issue for long-running Windows agent tasks:

1. Make process snapshots strictly single-flight and coalesced.
2. Do not launch a new snapshot while the previous collection is still running.
3. Add exponential backoff/circuit breaking after timeouts or Event 5858-style failures.
4. Remove global Win32_PerfFormattedData_PerfProc_Process enumeration from the hot path.
5. Use a persistent/native Windows process collector rather than spawning PowerShell per snapshot.
6. Provide a supported switch to disable all Windows host process sampling until a fix ships.

This long-run reproduction supports the overlap/backpressure hypothesis already discussed in #25453 and shows that the current implementation can sustain 100% CPU for hours on a 32-thread high-end CPU.

Happening all the time on my Win machine, Version 26.715.21425
Every Codex app start, and every task start in Codex.

This is a blocker, its taking all the cpu.

Report from codex, I think that can help to solve it:

Independent confirmation with direct Codex-log and Windows Event Viewer correlation.

## Environment

- Windows 11 23H2, build `22631.6199`, x64
- Intel Core i9-14900K, 32 logical processors
- Codex About version: `26.715.21425`
- MSIX package during capture: `OpenAI.Codex_26.715.2305.0_x64`
- Microsoft Store installation

## Reproduction

Launching Codex, starting a task, or starting Node inside a Codex task/shell causes `WmiPrvSE.exe` to rise to approximately **70–80% CPU**. Starting Node outside Codex does not produce the same behavior.

This indicates that Node is triggering Codex’s process sampler; Node itself is not making the WMI calls.

## Direct attribution

The Codex desktop logs repeatedly contain:

```text
warning [electron-sampler] Failed to collect child process snapshot

The recorded command launched by Codex is:

$cpuByPid = @{}

Get-CimInstance Win32_PerfFormattedData_PerfProc_Process |
  ForEach-Object {
    $cpuByPid[[int]$_.IDProcess] =
      [double]$_.PercentProcessorTime
  }

Get-CimInstance Win32_Process -Filter "ProcessId = ... OR ProcessId = ..." |
  Select-Object ProcessId,ParentProcessId,CommandLine,WorkingSetSize,... |
  ConvertTo-Json -Depth 2

This globally enumerates Win32_PerfFormattedData_PerfProc_Process, then submits another query containing a large list of process IDs.

Windows Event Viewer recorded 13 matching Event ID 5858 failures. Representative event:

Operation = Start IWbemServices::CreateInstanceEnum
Class = root\cimv2 : Win32_PerfFormattedData_PerfProc_Process
ResultCode = 0x800706BA
PossibleCause = Could not send status to client

Three exact timestamp correlations:

| Codex log, UTC | WMI Event Viewer, local time |
| --- | --- |
| 2026-07-17T21:28:09.802Z | 2026-07-18 00:28:10 |
| 2026-07-17T21:44:16.012Z | 2026-07-18 00:44:16 |
| 2026-07-17T22:32:32.358Z | 2026-07-18 01:32:33 |

The short-lived client PIDs and Could not send status to client result are consistent with Codex terminating or timing out its PowerShell sampler while WMI is still processing the enumeration.

During the investigation, Codex updated to MSIX package 26.715.3651.0. Read-only inspection confirms that this newer package still contains:

• the same PowerShell/WMI process sampler;
• the global Win32_PerfFormattedData_PerfProc_Process enumeration;
• a roughly 30-second sampler heartbeat;
• a roughly 5-second activity-trigger gate.

This is also reproduced in #33875 and appears related to #32562, #25453, and #22912.

Found the reason and the proper fix here on reddit! https://www.reddit.com/r/codex/comments/1uxpr1x/comment/oxt95ux

Encountered this issue yesterday. WMI process drains cpu resources. Closing codex-gpt windows app fixes it (win 11). Opening it again starts the issue again. Forced to use powershell CLI for now.

I updated the ChatGPT app to version 26.715.52143 (released 20.07.2026) via the Microsoft Store and am still experiencing this problem.
This is completely unacceptable, as I can't use my paid subscription if the software is hogging the CPU.

Same issue here; the following details were tested and provided by Codex 😃

---------------------------------

Independent confirmation from Windows 10 with the same WMI failure pattern.

Environment

• OS: Windows 10 x64
• Codex Desktop package: OpenAI.Codex_26.715.4045.0_x64
• Installation: Microsoft Store / MSIX

Observed behavior

While Codex Desktop is running, WmiPrvSE.exe can consume approximately 500–614% raw processor time, equivalent to about 5–6 logical CPU cores.

Fully exiting all Codex processes immediately returns CPU usage to normal:

• ChatGPT.exe
• codex.exe
• codex-code-mode-host.exe

Launching Codex again reproduces the issue.

WMI evidence

Microsoft-Windows-WMI-Activity/Operational records bursts of Event ID 5858 from many short-lived client PIDs. The repeated operations include:

SELECT __PATH, ProcessId, CSName, Caption, SessionId,
       ThreadCount, WorkingSetSize, KernelModeTime,
       UserModeTime, ParentProcessId
FROM Win32_Process
The following class is also repeatedly enumerated:
Win32_PerfFormattedData_PerfProc_Process
Observed result codes include:
0x80041006
0x80041032
0x80041033
0x800706BA
The hot WMI host was confirmed to be running the CIMWin32 provider from cimwin32.dll.
I also previously encountered this related Codex sandbox error:
helper_sandbox_lock_failed
SetNamedSecurityInfoW failed: 5
.codex\.sandbox-bin
Conclusion
This does not appear to be a permanently damaged WMI repository. The load starts with Codex Desktop and stops immediately when Codex is fully exited.
The behavior closely matches the repeated PowerShell/WMI process snapshot and missing backpressure described in this issue and related reports.
No prompt content, credentials, usernames, machine names, or private project paths are included in this report.