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

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

• #33940
• #33875

Powered by Codex Action

Yes, for me too. makes my PC unusable

Likewise

I reproduced a closely related case in the standalone Windows app and collected process-level evidence. In my reproduction, WmiPrvSE.exe was not the original source of the load—it was a secondary effect of a Git process creation storm triggered by the app's Changes/Review live query.

Evidence

During a 60-second completely idle capture, every 10-second window created approximately:

• 215–252 git.exe processes
• 128–157 taskkill.exe processes
• 280–325 conhost.exe processes

Using NtQueryInformationProcess to capture parent PIDs and command lines showed that the parent was the main ChatGPT.exe process. Repeated commands included:

git config --null --get core.fsmonitor
git hash-object -- <file>
git diff --no-index ...
taskkill.exe /pid <previous-git-pid> /t /f

The pattern appeared to be:

1. The app starts a Changes/Review snapshot.
2. It runs per-file Git hash/diff operations.
3. A new live-query refresh arrives before the previous snapshot completes.
4. The previous Git processes are killed with taskkill.
5. The entire operation immediately starts again.

This continued even with a brand-new/idle conversation and no running agent turn.

Trigger in my reproduction

The affected repository had:

• 31 tracked modified files
• 2,286 untracked files

Most untracked files were generated media, build output, tool state, and a standalone nested project. The same app behaved normally after reducing the dirty working-tree scope.

I added the large generated/local directories to .git/info/exclude, reducing the untracked count from 2,286 to 10, and then committed the intended tracked changes.

After that:

• New git.exe processes in a 15-second capture: 0
• New taskkill.exe processes: 0
• System CPU: approximately 92% → 14%
• WMI Provider Host: approximately 39% → 0.6%
• Defender: approximately 8% → 0.3%
• Codex: approximately 5% → 1.5%

No failing MCP was involved in this reproduction.

Workarounds

1. Commit or stash intended changes so the working tree is clean.
2. Add generated files, media, build outputs, nested projects, and local tool state to .gitignore or .git/info/exclude.
3. Use a clean Git worktree for the standalone app.
4. For repositories that must remain heavily dirty, temporarily use the CLI or VS Code extension.

Disabling Git system-wide or removing .git is not recommended.

Possible application-side fixes

• Coalesce/debounce repository watcher invalidations.
• Do not restart a full Review snapshot while the previous one is still in flight.
• Avoid spawning a separate Git process for every file where possible.
• Apply cancellation backoff instead of repeatedly starting Git and immediately calling taskkill.
• Cap or lazily load large untracked-file sets.
• Avoid retriggering live queries from Git index/watch events produced during the app's own Git operations.

This appears to explain why the standalone app triggers WMI/Defender CPU while the VS Code extension does not: the standalone Changes/Review implementation creates and cancels a very large number of short-lived local processes.

Additional evidence from another affected Windows machine, closely matching this issue.

Environment

• Codex Desktop: 26.715.8383.0, Microsoft Store, Windows x64
• VS Code: 1.129.1
• VS Code Codex extension: openai.chatgpt@26.715.31925

Reproduction and differential result

• Opening one specific repository in Codex Desktop causes sustained near-100% whole-system CPU and severe Windows UI lag.
• Switching to another Desktop project does not stop the load; fully exiting Desktop does.
• Sparse/clean repository probes produce only a temporary startup spike and recover.
• The original repository currently has 49 tracked changes and 235 untracked files, so a dirty-worktree live-query amplifier is plausible, although the count is lower than the 2,286-file reproduction already reported here.
• The same engine is available through the installed VS Code extension, which avoids the Desktop Electron sampler path.

Trace evidence

A 193-second WPR capture contained 72,292,040 events with zero lost events. During the trace interval, WMI Activity recorded failed full root\\cimv2:Win32_Process enumerations with result codes including 0x80041032 and 0x800706BA from short-lived client PIDs.

Codex Desktop logs in the same interval show PowerShell/CIM commands for:

Get-CimInstance Win32_Process
Get-CimInstance Win32_PerfFormattedData_PerfProc_Process

One WMI failure and the corresponding bundled-plugin WMI failure in the Codex log were separated by approximately 4 ms. Inspection of the installed bundle also found the electron-sampler process snapshot path, a 30-second heartbeat, a 5-second minimum non-heartbeat interval, and no supported production setting to disable the sampler.

This supports two interacting Desktop-only mechanisms:

1. repository Changes/Review refreshes can repeatedly start and cancel Git work for a dirty project;
2. the Desktop-wide process sampler and bundled-plugin reconciliation perform PowerShell/WMI snapshots, amplifying short-lived process churn and continuing after the user switches projects.

Confirmed local mitigation

The repository was cleaned on a separate local branch. Generated and machine-local directories were excluded from Git status without deleting their files, and intended source/documentation changes were committed. Git status changed from:

• 49 tracked changes
• 235 untracked files

to 0 status lines.

After this change, the exact original Desktop project was tested through four stages:

1. project open: a short CPU spike, then recovery after approximately 10-15 seconds;
2. no-tool conversation: successful, no sustained saturation;
3. two-file context read: successful, a temporary CPU rise to approximately 40%, then recovery;
4. terminal-backed git status --short: successful, 0 output lines, no process storm restart.

Before cleaning the repository, opening this project caused sustained near-100% CPU and whole-system lag until Codex Desktop was exited. This controlled before/after result strongly supports dirty Changes/Review state as the project-specific trigger or primary amplifier, with the Desktop WMI sampler responsible for much of the system-wide cost.

The raw ETL was not attached publicly and was deleted after redacted reports were preserved. Redacted tracerpt XML, a trace summary, and timestamp-correlated log excerpts are available on request.

my pc is also affected.

I am having the same issue. Windows 11 machine with the MSFT store version of the Codex app.

The issue is with the git untracked files. I had 2700 untracked files in one of the repos. What solved it for me is to either gitignore the files or just commit them ;) WMI PRovider went form 40%+ CPU usage to <1%

Following up with the downloadable workaround produced from the process-level reproduction discussed in this issue.

I published a single-file Windows launcher for the original Microsoft Store/MSIX Codex app:

• Repository: https://github.com/suiyuebaobao/codex-git-refresh-workaround
• Direct download: https://raw.githubusercontent.com/suiyuebaobao/codex-git-refresh-workaround/main/Codex-Git-Disabled.cmd

It starts Codex with a process-scoped GIT_DIR=NUL. On my machine, the stable trace changed from 247 new git.exe and 137 new taskkill.exe processes per 10 seconds to 0 and 0 over 15 seconds; WMI Provider Host fell from about 6.6% to 0.9%.

Usage: fully exit Codex from the Windows system tray, then run the script.

This is an unofficial workaround, not an upstream fix. It deliberately disables or limits Review, Changes, branch detection, commit, and other Git-backed Codex features. It does not patch Codex, modify repositories or Git configuration, write system environment variables, require elevation, terminate processes, or remove chat history. Launching Codex normally restores Git integration.

<img width="2559" height="1439" alt="Image" src="https://github.com/user-attachments/assets/1a5ab3cc-fbae-4c0e-aae8-9830ba04035f" />

I just opened the APP!!
Windows Defender also uses too much CPU at that time but I have a hard limit just to use 5% of CPU.
Not optimized NGL

I can reproduce this on the newer Microsoft Store build 26.715.9868.0. The app updated from 26.715.4045.0 today, but the WMI CPU problem persists after the update.

Environment:

• Windows 11 x64
• Microsoft Store/MSIX standalone desktop app
• Package: OpenAI.Codex_26.715.9868.0_x64__2p2nqsd0c76g0

Reproduction:

1. Fully close the ChatGPT/Codex desktop app: system CPU returns to normal.
2. Launch the standalone desktop app and leave it open.
3. WmiPrvSE.exe immediately becomes the dominant CPU consumer.
4. Fully close the app again: the abnormal load stops.

Two read-only short-window CPU delta samples, normalized across all logical processors and taken without issuing WMI queries during the sampling window:

| Sample | WmiPrvSE.exe | Winmgmt svchost | ChatGPT.exe |
|---|---:|---:|---:|
| 10 seconds | 24.8% total-system CPU | 6.8% | 1.6% |
| 6 seconds | 22.1% total-system CPU | 6.4% | 1.4% |

A separate Windows performance-counter check showed the hot WmiPrvSE.exe instance at approximately 635–702% per-process processor time, i.e. roughly 6–7 logical cores.

The desktop logs from the same machine/build family contain repeated:

warning [electron-sampler] Failed to collect child process snapshot

The failing sampler command queries both:

Get-CimInstance Win32_PerfFormattedData_PerfProc_Process
Get-CimInstance Win32_Process

The issue is therefore not renderer/GPU load: the packaged ChatGPT.exe itself remains around 1–2%, while WMI Provider Host and Winmgmt consume most of the CPU. Toggling hardware acceleration is unlikely to address this path.

The app update also caused temporary C: activity, but after startup the repeatable blocker remains the WMI CPU load. No project paths, prompts, credentials, or raw private logs are included here.

Please consider disabling or rate-limiting the Windows electron process sampler when the WMI snapshot fails, adding single-flight/backoff, or replacing the PowerShell/WMI polling path with a native process enumeration API.

Opening any conversation starts sustained WMI CPU usage.
Switching to another conversation does not stop it.
Opening Settings immediately stops WMI activity.

WMI Event ID 5858:
Win32_PerfFormattedData_PerfProc_Process
ResultCode = 0x800706BA
PossibleCause = Could not send status to client

Opening any conversation starts sustained WMI CPU usage. Switching to another conversation does not stop it.

Reproduced.

Opening Settings immediately stops WMI activity.

Not reproduced.

My system:
Win10
Codex 26.715.72359

The issue is with the git untracked files. I had 2700 untracked files in one of the repos. What solved it for me is to either gitignore the files or just commit them ;) WMI PRovider went form 40%+ CPU usage to <1%

This worked for me. Had codex do a review of the files and come up with a plan to either delete them or ignore. No issues since then.

This worked for me. Had codex do a review of the files and come up with a plan to either delete them or ignore. No issues since then.

Did you this with every project that attaced to codex? Or only with one opened project?

As I asked the Codex to research this error it says that only count of active processes affect this slowing.

Did you this with every project that attaced to codex? Or only with one opened project? As I asked the Codex to research this error it says that only count of active processes affect this slowing.

I only have one project so thats the project that it cleaned up.

> This worked for me. Had codex do a review of the files and come up with a plan to either delete them or ignore. No issues since then. Did you this with every project that attaced to codex? Or only with one opened project? As I asked the Codex to research this error it says that only count of active processes affect this slowing.

i had one project with this amount of untracked files. but i was switching between this one and one another. as far as i can tell it didn't matter which one i was using the slowdown was there either way. But i don't know how Codex is keeping project as active. i would clean everything to be sure.

I can confirm this still happens in Version 26.715.72359, Released 22 Jul 2026 on Windows Pro Version 21H2 (OS Build 19044.3086).

The issue is with the git untracked files. I had 2700 untracked files in one of the repos. What solved it for me is to either gitignore the files or just commit them ;) WMI PRovider went form 40%+ CPU usage to <1%

I confirm the issue on my PC too and committing the git untracked files resolved it:
Edition Windows 11 Pro
Version 25H2
OS build 26200.8457

That's carzy! I run Codex and have to wait a few minutes until my PC will be usable again...

<img width="879" height="362" alt="Image" src="https://github.com/user-attachments/assets/f486ec9d-812e-4d39-a56e-23c7d15bf375" />

Yes, I had 13k untracked files in my projects, but this screenshot I made after fix untracked files count to ~40 and completely restart the Codex.

A tip: you can ask Codex to analyze latest Codex's logs to see which projects have some issues with git

I can confirm this still happens in Edition Windows 11 Pro, Version 23H2 (22631)

CPU peaks is much shorter today:

<img width="607" height="269" alt="Image" src="https://github.com/user-attachments/assets/6a86d6f9-a787-445c-a10f-8ca982d6fc7d" />

Maybe I had to restart PC after fix untracked files (13k to 40), or maybe v26.721.31836 has fix of this trouble.