Skip to content

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

Closed as duplicate
Closed as duplicate
[P0 regression] Windows desktop launch saturates all CPU cores via WmiPrvSE (26.715.10079.0)#34879
Labels
appIssues related to the Codex desktop appbugSomething isn't workingperformancewindows-osIssues related to Codex on Windows systems

Description

@askxue
askxue
opened on Jul 23, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    performance
    on Jul 23, 2026

  2. github-actions commented on Jul 23, 2026

    @github-actions
    github-actionsBot
    on Jul 23, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. askxue commented on Jul 23, 2026

    @askxue
    askxue
    on Jul 23, 2026
    Author
    Image

  4. zscAZA commented on Jul 23, 2026

    @zscAZA
    zscAZA
    on Jul 23, 2026

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

  5. askxue commented on Jul 24, 2026

    @askxue
    askxue
    on Jul 24, 2026 – with ChatGPT Codex Connector
    Author

    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: 
      taskkill.exe /pid <pid> /t /f
    • During the storm, WMI Event 5858 repeatedly reported full Win32_Process enumeration: 
      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.

  6. zscAZA commented on Jul 24, 2026

    @zscAZA
    zscAZA
    on Jul 24, 2026

    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

  7. chess-oai
    closed this as a duplicateof Windows Desktop: unbounded taskkill.exe/conhost.exe cleanup storm exhausts WMI #34260 on Aug 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformancewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions