Repository navigation
[Windows][26.715.10079.0] Opening Codex spawns rapid Git/PowerShell churn and drives WMI + Defender CPU to ~60% #34854
Description
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
- Start the Microsoft Store ChatGPT/Codex desktop app.
- Open Codex, a new task, an existing conversation, or the Review UI.
- Observe Task Manager.
WMI Provider HostandAntimalware Service Executablebegin consuming substantial CPU, and total CPU can approach 90%.- 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.exeprocesses - 15 new
conhost.exeprocesses - 9 new
powershell.exeprocesses - 2 new
pwsh.exeprocesses
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_BIOSWin32_BaseBoardWin32_ProcessorWin32_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:
- High CPU Usage Triggered by Windows Defender & WMI When Launching Codex Desktop on Windows 10 #33875
- [Windows][26.715.8383.0] Desktop app appears to trigger sustained WMI/Defender CPU usage that stops immediately on full app exit #34666
- Standalone Windows app triggers WMI Provider Host (90–100% CPU) when opening one project, while the same project works normally in the VS Code extension #34014
- Codex desktop app (Windows) pins CPU via WMI — process-monitoring loop spawns ~10 helper processes/sec during any shell execution #34592
- Windows Codex Desktop spawns powershell.exe every second for full process polling, causing high CPU usage #25453
- Codex Desktop Creates Empty
.gitDirectories, Then Repeatedly Scans Them and Triggers Windows Defender High CPU #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.
Activity
github-actions commentedon Jul 23, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
5168413518 commentedon Oct 8, 2026
The repeated Git helper-process part of this report matches our Windows 10 observation. The following workaround removed that Git churn on one machine, but I cannot claim it fixes the separate WMI/PowerShell symptoms.
Confirmed Windows 10 workaround: accidental Git repo at
%USERPROFILE%was causing idle Codex Git scansI reproduced high idle CPU/heat in the Microsoft Store ChatGPT/Codex desktop app 26.1002.7124.0 on Windows 10. No local agent task was running; fully exiting the app reduced the load.
Evidence before the change
ChatGPT.exewas launching repeatedgit.exesubprocesses. One captured command wasgit ... ls-files --cached -z -- AppData/Local/Packages/....git -C %USERPROFILE% rev-parse --show-toplevelresolved to the entire user-profile directory.%USERPROFILE%\.gitexisted (withHEAD/ normal Git structure, but no commits, index, or remotes). Persisted Codex project directories nested under%USERPROFILE%\.codex\.chatgpt-projects\...thus inherited the profile-level Git root..gitand was unaffected.Reversible workaround that worked here
%USERPROFILE%\.gitis actually needed. Do not rename/remove it if your home directory is intentionally a Git repository.%USERPROFILE%\.gitto a timestamped.git_backup_YYYY-MM-DD; do not delete it.After: 0
git.exePIDs in 60 consecutive samples over ~13 seconds, and essentially zero CPU time attributable to the idle ChatGPT process group during that sample. The affected laptop's temperature improved. Git, Codex CLI, and an actual Work Local Git read test in the independent development repo still worked; no project files/Git history were changed.This is one confirmed local mitigation, not an upstream fix. It does not establish the cause of unrelated
taskkill.exe/WMI polling bugs or UI freezes. The likely product improvement is to avoid scanning an accidentally inherited ancestor repo outside the saved workspace scope, and bound/debounce background Git refreshes.— Пчеличко (Pchelichko)