Codex desktop app (Windows) pins CPU via WMI — process-monitoring loop spawns ~10 helper processes/sec during any shell execution

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

• #34580
• #34050
• #34158

Powered by Codex Action

Additional reproduction signal: this stopped immediately after I committed all pending Git changes in a very dirty worktree.

Before the commit, using Codex shell features repeatedly correlated with Git subprocess activity, taskkill/conhost churn, elevated WMI Provider Host CPU, and eventually Codex becoming unresponsive while Windows could no longer launch other applications. After committing the pending changes, taskkill activity returned to idle, WMI CPU returned near idle, and the freeze has not recurred.

This points to a workspace-scanning/backpressure bug triggered by a heavily dirty Git worktree, possibly a retry/cancellation loop involving Git subprocesses, process cleanup, and WMI process monitoring.

System: Windows 11 x64, Intel Core i9-13900K, 64 GB RAM, NVIDIA GeForce RTX 3090 (24 GB).

Privacy note: repository/project names, local paths, account identifiers, conversation identifiers, and raw logs are intentionally omitted.

Additional upstream trigger: automatic Git review queries

I reproduced the same Windows WMI/process-monitoring amplification without running any shell command or agent tool.

On package 26.715.10079.0, merely opening a conversation inside a dirty Git project caused the renderer to issue automatic review-summary and branch-diff-stats queries.

An approximately 11-second WPR capture contained 2,422 spawned processes, including:

• 452 git hash-object
• 486 git config
• 483 taskkill.exe
• 969 conhost.exe

WmiPrvSE.exe accounted for approximately 32.71% system CPU, and Winmgmt accounted for another 9.68%. Total system CPU approached 100% for 15-30 seconds on every conversation open.

Disabling the Electron app-state process snapshot path alone did not eliminate the spike because the upstream Git fan-out continued.

Holding that mitigation constant, disabling only the renderer's review-summary and branch-diff-stats live queries eliminated the trigger. A subsequent 30-second capture showed 0% WmiPrvSE.exe CPU and no new matching WMI events.

This suggests two compounding defects:

1. Automatic Git review queries create excessive short-lived child processes during ordinary chat navigation.
2. Windows child-process monitoring and cleanup amplify that fan-out through WMI, PowerShell, taskkill.exe, and conhost.exe.

The process-monitoring fix should therefore cover Git/review worker children as well as explicit shell executions. Related review-query tracking is in #30820.

Still reproducible on Windows desktop 26.721.4979.0 (2026-07-27)

I can confirm that this issue persists on a substantially newer stable MSIX build.

Environment

• Codex Windows desktop: OpenAI.Codex_26.721.4979.0_x64
• Windows 11 x64 (26100.8875)
• AMD Ryzen 9 9950X3D, 32 logical processors
• 96 GB RAM
• NVIDIA RTX 4090

Impact

WmiPrvSE.exe remains a major CPU consumer while local Codex tasks are active. The machine develops periodic mouse, window-dragging, and IME/input stalls despite high-end hardware. Audio and video playback can remain uninterrupted, suggesting latency/input starvation rather than a normal whole-system compute bottleneck. Fully exiting Codex removes the recurring stutter.

Correlated Windows event evidence

The existing Microsoft-Windows-WMI-Activity/Operational log shows repeated Event 5858 entries with many distinct, short-lived ClientProcessId values. Operations include:

IWbemServices::CreateInstanceEnum - root\cimv2 : Win32_Process

and large queries of the form:

SELECT * FROM Win32_Process WHERE ProcessId = ... OR ProcessId = ...

Failures repeatedly include:

0x80041032
0x800706BA (Could not send status to client)

The client processes often disappear before WMI can return status. Event 5857 simultaneously shows the CIMWin32 provider starting in WmiPrvSE.exe via wmipcima.dll.

The classic Windows PowerShell log independently records the exact repeated HostApplication command:

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

It also records the heavier periodic sampler:

Get-CimInstance Win32_PerfFormattedData_PerfProc_Process
Get-CimInstance Win32_Process

with command line, working set, CPU percentage, and process-age projection. The commands recur every few seconds, and overlapping local Codex task/tool activity amplifies the rate.

This was reproduced after app updates and restarts. The active project workloads themselves do not intentionally call WMI; one task explicitly prohibited WMI/CIM polling and watchdogs, yet the desktop monitoring commands continued.

Conclusion / request

This strongly confirms that the desktop app's Windows process/performance supervision path is still using repeated full-machine WMI enumeration on 26.721.4979.0. Please prioritize a native process snapshot implementation or, at minimum, single-flight execution, strict throttling, exponential backoff/circuit breaking, and cancellation that does not create another helper-process/WMI feedback loop.

Raw logs are not attached because they contain local process metadata and paths, but sanitized timestamps/query summaries can be provided if maintainers request them.