[Windows][26.715.10079.0] Opening Codex spawns rapid Git/PowerShell churn and drives WMI + Defender CPU to ~60%

Open 💬 1 comment Opened Jul 23, 2026 by 1656970772
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

OpenAI.Codex 26.715.10079.0 from the Microsoft Store (unified ChatGPT/Codex Windows desktop app).

Platform

  • Windows 11 Pro 24H2, build 26100.8246, x64
  • Intel Core Ultra 7 270K Plus
  • Microsoft Defender real-time protection enabled

Issue

Opening Codex, entering the Home/New Chat/conversation/Review UI, or keeping the app open causes an immediate and severe system-wide CPU spike.

In one Task Manager capture:

  • Total CPU: approximately 89%
  • WMI Provider Host: 31.3%
  • Antimalware Service Executable: 29.9%
  • The ChatGPT/Codex process group was also active and using more than 3 GB RAM

The machine returns to normal when Codex is no longer triggering the workload. This behavior is reproducible specifically when Codex is opened or used.

Steps to reproduce

  1. Start the Microsoft Store ChatGPT/Codex desktop app.
  2. Open Codex, a new task, an existing conversation, or the Review UI.
  3. Observe Task Manager.
  4. WMI Provider Host and Antimalware Service Executable begin consuming substantial CPU, and total CPU can approach 90%.
  5. Close/exit Codex and observe the workload subside.

Additional process-churn evidence

A short process-start sample was taken while Codex was active. In only 8 seconds, it observed:

  • 31 new git.exe processes
  • 15 new conhost.exe processes
  • 9 new powershell.exe processes
  • 2 new pwsh.exe processes

This suggests that Defender and WMI may be downstream amplifiers of rapid helper-process creation rather than the original source of the workload.

Recent WMI Activity also contained queries involving:

  • Win32_BIOS
  • Win32_BaseBoard
  • Win32_Processor
  • Win32_VideoController

The combination looks consistent with repeated system-inventory polling and/or repository/process monitoring.

Expected behavior

Codex should not repeatedly spawn Git and PowerShell helpers or continuously query WMI while the UI is idle. Background monitoring should be bounded, cached, or event-driven so that Defender and WMI return to an idle state.

Actual behavior

Launching or using Codex causes rapid helper-process churn and sustained WMI/Defender CPU usage. The visible CPU consumers are Windows components, but the workload begins with Codex activity.

Related reports

This appears to be another independent reproduction of the same Windows performance problem reported in:

  • #33875
  • #34666
  • #34014
  • #34592
  • #25453
  • #29911

The important difference in this report is the measured helper-process creation rate on app version 26.715.10079.0.

I can collect additional sanitized ETW/WMI or process-lifecycle diagnostics if maintainers specify the preferred trace providers and fields.

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 1 month ago

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

  • #33875
  • #33940
  • #34594
  • #34592
  • #34666

Powered by Codex Action