›_ Codex Issues
Codex Issues / #34879

[P0 regression] Windows desktop launch saturates all CPU cores via WmiPrvSE (26.715.10079.0)

Resolved 💬 5 comments Opened Jul 23, 2026 by askxue Closed Aug 5, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Launching the Codex Windows desktop app immediately causes severe system-wide CPU saturation. All 32 logical processors spike to or remain near 100%, making the machine and the app effectively unusable. Closing Codex is the only immediate way to recover.

This appears to be a current-version regression or severe escalation of the WMI/electron-sampler behavior reported in #22912. In this case, the visible top CPU consumer is WMI Provider Host (WmiPrvSE.exe), rather than the Codex renderer itself.

Severity: P0 / product unusable on this machine. Please prioritize a fail-safe so diagnostic sampling cannot saturate the host CPU.

Environment

  • Codex Windows desktop stable package: OpenAI.Codex_26.715.10079.0_x64
  • OS: Windows 11 Pro, x64, build 10.0.26200
  • CPU: AMD Ryzen 9 7945HX, 32 logical processors
  • RAM: 63.2 GB
  • GPUs:
  • NVIDIA GeForce RTX 4060 Laptop GPU, driver 32.0.15.8157
  • AMD Radeon 610M, driver 32.0.11016.14003
  • Observed: 2026-07-23

Steps to reproduce

  1. Start the Codex Windows desktop app normally.
  2. Do not start any agent task; simply allow the desktop app to open.
  3. Open Windows Resource Monitor or Task Manager.
  4. Observe system CPU rapidly saturating across all logical processors.
  5. Observe WmiPrvSE.exe / WMI Provider Host as the leading CPU consumer.
  6. Close Codex; the machine becomes usable again.

The behavior is reproducible on app launch and prevents normal use of the product.

Expected behavior

Opening Codex should leave the system responsive. Background diagnostics or process sampling must be bounded, low-frequency, cancellable, and should back off permanently after repeated failures.

Actual behavior

  • CPU saturates across all 32 logical processors immediately after launch.
  • Windows becomes severely degraded and Codex cannot be used normally.
  • Resource Monitor identifies WmiPrvSE.exe as the primary visible CPU consumer.
  • Multiple suspended/active PowerShell and Node processes are also visible during the event.

Log evidence

The current Codex desktop logs repeatedly contain:

warning [electron-sampler] Failed to collect child process snapshot
Command failed: powershell.exe -NoProfile -NonInteractive -Command
$ErrorActionPreference = 'Stop';
Get-CimInstance Win32_Process |
  Select-Object ProcessId,ParentProcessId |
  ConvertTo-Json -Depth 2

The same logs also contain repeated attempts involving:

Get-CimInstance Win32_PerfFormattedData_PerfProc_Process
Get-CimInstance Win32_Process

In one launch/session on 26.715.10079.0, the log recorded 77 electron-sampler failures in 17 minutes 40 seconds (05:32:57Z through 05:50:37Z), approximately one failure every 14 seconds. Other sessions on the same build recorded 154 and 371 failures.

This repeated WMI process enumeration closely matches the observed WmiPrvSE.exe CPU load.

Relationship to existing reports

Potentially related: #22912, which reports intermittent Windows freezes while electron-sampler repeatedly fails WMI process snapshots in the sandbox.

This report is materially more severe and is on the current 26.715.10079.0 build:

  • immediate on app launch;
  • system-wide CPU saturation across 32 logical processors;
  • WmiPrvSE.exe is the leading consumer;
  • the product is effectively unusable rather than intermittently stalled.

Requested mitigation

Please add an urgent fail-safe/backoff around Windows WMI process sampling. After the first failure(s), stop retrying or switch to a cheaper data source. Diagnostic sampling should never be able to create an unbounded WMI/PowerShell loop that destabilizes the host.

A Resource Monitor screenshot showing the per-core saturation and process list will be attached to this issue.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34854
  • #34580
  • #34594
  • #33940
  • #33875

Powered by Codex Action

askxue · 1 month ago

<img width="1693" height="972" alt="Image" src="https://github.com/user-attachments/assets/fdf8a30d-6f9d-48f5-9842-844502b7b144" />

zscAZA · 1 month ago

I encountered this issue as well, which prevented me from using Codex at all, resulting in a waste of my subscription

askxue · 1 month ago

Update: root-cause evidence, local mitigation, and overnight validation

I investigated this further on the same Windows 11 machine with Codex Desktop 26.715.10079.0. The local diagnostic build has now been used for a full evening/overnight of real project work, including normal task execution and image paste, with no recurrence of the 100% CPU / WmiPrvSE storm.

Evidence from ETW/WPR and process tracing

  • In the long ETW trace, WmiPrvSE.exe was overwhelmingly dominant (2,801,331 sampled CPU events).
  • In the relevant time window, 930,957 samples were captured; 930,339 had stacks, and 903,500 inclusive samples passed through cimwin32.dll.
  • One secondary startup trigger was Chromium's chrome.mojom.ProcessorMetrics. Its child started at 58.348 s, exited at 58.469 s, and WMI CPU began in second 58. The observed queries included:
  • SELECT Family,VirtualizationFirmwareEnabled FROM Win32_Processor
  • SELECT HypervisorPresent FROM Win32_ComputerSystem
  • Disabling that sampler removed those queries, but did not by itself eliminate the full CPU saturation.
  • A Toolhelp-based parent/child capture then showed many short-lived taskkill.exe processes as direct children of the desktop root ChatGPT.exe, alongside concurrent Git helper processes.
  • The bundled JS cleanup path contains a Windows process-tree termination function equivalent to:

``js
taskkill.exe /pid <pid> /t /f
``

  • During the storm, WMI Event 5858 repeatedly reported full Win32_Process enumeration:

``sql
SELECT __PATH, ProcessId, CSName, Caption, SessionId, ThreadCount,
WorkingSetSize, KernelModeTime, UserModeTime, ParentProcessId
FROM Win32_Process
`
The task cancellation/timeout path could run concurrently, creating a positive feedback loop: more child-process churn -> more taskkill /t` invocations -> more WMI process enumeration -> desktop/CLI starvation.

Local A/B mitigation

For diagnostic isolation I changed the Windows cleanup path from taskkill /t to terminating the already-held child process handle directly (equivalent to child.kill("SIGKILL")). The diagnostic copy also disabled the Electron/Chromium WMI telemetry samplers noted above.

Results after the process-cleanup change:

  • Before: WmiPrvSE at roughly 50–70%, total CPU at 100%, continuous taskkill.exe / conhost.exe / Git churn, and repeated Event 5858 entries.
  • After: a controlled 15-second run produced 0 taskkill.exe processes and 0 new WMI ExecQuery events.
  • WmiPrvSE CPU delta was 0 for 20 consecutive one-second samples.
  • The desktop remained usable through an evening/overnight of real work, with no recurrence.

Important isolation caveat

The local diagnostic build contains both mitigations, so upstream should validate them independently. The A/B result strongly implicates the unbounded/concurrent taskkill /t cleanup path as the main feedback-loop trigger, while the ProcessorMetrics/Electron samplers are additional WMI startup load.

Suggested upstream fix

  1. Put spawned Git/command processes in a Windows Job Object with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE.
  2. When only the direct child must be stopped, terminate the existing process handle directly.
  3. If descendant discovery is unavoidable, use a bounded native snapshot (Toolhelp or NtQuerySystemInformation) rather than repeated WMI-backed taskkill /t.
  4. Make cleanup single-flight and add timeout/backoff/circuit-breaking so failed or slow cleanup cannot spawn unbounded helpers.
  5. Avoid WMI full-process enumeration in high-frequency telemetry paths; throttle and cache ProcessorMetrics data.

Related reports: #34260, #34592, #33776, #22912.

I have retained the raw ETL and sanitized process/stack tables locally. I am not attaching the raw trace because it contains local paths and process metadata, but I can provide a smaller sanitized artifact if maintainers need it.

zscAZA · 1 month ago

The issue on my end has been resolved. It was caused by a large number of files that were neither tracked by Git nor added to the .gitignore file. Upon checking my code, I discovered that opencode had previously generated a node_modules directory within my own directory, which contained over 15,000 untracked files. After removing the node_modules directory, the high CPU usage issue with WMI disappeared. hope this helps you