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

Start by tracing the desktop app's exec-monitoring machinery around the app-server launched with -c features.code_mode_host=true, then reproduce the issue with a long shell command while capturing child processes and WMI-Activity events. Done means shell execution no longer causes continuous PowerShell, WMI, and taskkill churn or severe CPU saturation, while monitoring still works.

What version of the Codex App are you using (From “About Codex” dialog)?

Codex desktop app 26.715.7063.0 (MSIX, OpenAI.Codex_2p2nqsd0c76g0), Windows 11 Pro 10.0.26200, 16-core machine

What subscription do you have?

MAX

What platform is your computer?

Windows 11

What issue are you seeing?

Summary
The desktop app's exec-monitoring machinery (app-server launched with
-c features.code_mode_host=true) drives WMI Provider Host (WmiPrvSE.exe)
to ~50% CPU and total system load to ~99% whenever a conversation executes
shell work. The load is sustained for the entire duration of the executed
command (observed across a multi-minute pytest run), not just at startup.
What the app is doing (observed via process capture and WMI-Activity 5858 events)
In a 25-second window, ChatGPT.exe spawned 235 short-lived child processes:

• Multiple CONCURRENT copies of:
  powershell.exe -NoProfile -NonInteractive -Command
  "Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId | ConvertTo-Json"
  (full process-table enumeration, several per second)
• A per-PID CPU sampler enumerating Win32_PerfFormattedData_PerfProc_Process
  (i.e. performance counters for EVERY process on the machine) with a
  ~60-PID OR-filter Win32_Process query appended
• taskkill.exe /pid /t /f on each helper afterwards
• Periodic git status --porcelain polls on individual watched files
  Every one of these WMI enumerations is serviced by WmiPrvSE (CIMWin32 and
  WmiPerfInst provider hosts), which is what pins the CPU. The WMI-Activity
  operational log shows dozens of distinct short-lived ClientProcessIds each
  issuing IWbemServices::CreateInstanceEnum root\cimv2:Win32_Process.
  Impact
• WmiPrvSE at 50%+ and total CPU ~99% on a 16-core machine while any
  conversation runs shell work (e.g. a test suite).
• Knock-on load from Windows Defender scanning each spawned helper and
  WMI servicing the query volume.
• Killing ChatGPT.exe immediately returns the machine to <10% CPU.

What steps can reproduce the bug?

Repro

1. Open the desktop app on Windows.
2. Ask a conversation to run any long shell command (e.g. pytest -q on a
   medium test suite).
3. Watch Task Manager: WmiPrvSE climbs to ~50%, total CPU to ~90%+, and
   powershell.exe/taskkill.exe churn continuously with ChatGPT.exe as parent.

What is the expected behavior?

No response

Additional information

Notes

• Headless codex exec (CLI) does NOT exhibit this — the monitoring loop
  appears to live in the desktop app layer only.
• Separate but related: the workspace scanner also spawns one git hash-object
  per untracked-not-ignored file plus a taskkill per helper on every
  working-tree change, which produces the same WmiPrvSE saturation on repos
  with large untracked sets (observed 2026-07-17 on an earlier build).
  Suggested fixes
• Batch/throttle the process-tree sampling (one enumeration per interval,
  not several concurrent full-table dumps per second).
• Query only the tracked PIDs' subtree instead of enumerating all processes
  and all perf-counter instances.
• Use native APIs (NtQuerySystemInformation / toolhelp snapshot) instead of
  spawning powershell.exe + WMI per sample.