Skip to content

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

Open
Open
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
Labels
appIssues related to the Codex desktop appbugSomething isn't workingperformancewindows-osIssues related to Codex on Windows systems

Description

@tmyAudience
tmyAudience
opened on Jul 18, 2026

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

26.715.12143

What subscription do you have?

ChatGPT Plus

What platform is your computer?

No response

What issue are you seeing?

Summary

The standalone Codex Windows app causes WMI Provider Host (WmiPrvSE.exe) to consume approximately 90–100% CPU whenever I open a specific project.

The problem is reproducible even when I create a completely new chat in that project and do not send any message or run any task.

The same project works normally with the Codex extension in VS Code, without high WMI CPU usage.

Environment

  • Codex standalone Windows app version: 26.715.12143
  • Operating system: Windows 11
  • Affected component: Standalone Codex Windows app
  • Unaffected component: Codex extension in VS Code

Windows version/build:

Please insert the output of `winver` here.

### What steps can reproduce the bug?

### Environment

- Codex App: 26.715.12143
- Windows 11 x64
- ChatGPT Plus

### Steps to reproduce

1. Launch the standalone Codex Windows app.
2. Open the affected local project.
3. Wait until the project finishes loading.
4. Open any existing conversation **or create a brand-new empty conversation**.
5. Do **not** send any prompt and do **not** run any task.
6. Open Windows Task Manager.

### Actual behavior

Immediately after entering the project:

- `WMI Provider Host (WmiPrvSE.exe)` jumps to 90–100% CPU.
- The application becomes sluggish.
- Windows Event Viewer continuously logs WMI Activity Event ID 5858.
- The issue occurs before any prompt is sent.

The problem is reproducible every time.

### Expected behavior

Opening a project or an empty conversation should not trigger continuous WMI activity or high CPU usage.

### Additional observations

- The exact same project works normally in the Codex VS Code extension.
- The issue only occurs in the standalone Windows app.
- Other projects appear to work normally.

This issue appears to be associated with the standalone application's project/workspace initialization rather than conversation content, because creating a brand-new empty conversation in the same project reproduces the issue immediately.

### What is the expected behavior?

_No response_

### Additional information

_No response_

Activity

  1. tmyAudience
    added
    appIssues related to the Codex desktop app
    on Jul 18, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    performance
    on Jul 18, 2026

  3. github-actions commented on Jul 18, 2026

    @github-actions
    github-actionsbot
    on Jul 18, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. bermuda99 commented on Jul 19, 2026

    @bermuda99
    bermuda99
    on Jul 19, 2026

    Yes, for me too. makes my PC unusable

  5. Eigenwise commented on Jul 20, 2026

    @Eigenwise
    Eigenwise
    on Jul 20, 2026

    Likewise

  6. huanxuan123 commented on Jul 20, 2026

    @huanxuan123
    huanxuan123
    on Jul 20, 2026

    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.

  7. sakuralkk commented on Jul 21, 2026

    @sakuralkk
    sakuralkk
    on Jul 21, 2026

    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.

  8. xszaryx commented on Jul 21, 2026

    @xszaryx
    xszaryx
    on Jul 21, 2026

    my pc is also affected.

  9. Wado729 commented on Jul 21, 2026

    @Wado729
    Wado729
    on Jul 21, 2026

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

  10. xszaryx commented on Jul 21, 2026

    @xszaryx
    xszaryx
    on Jul 21, 2026

    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%

  11. suiyuebaobao commented on Jul 22, 2026

    @suiyuebaobao
    suiyuebaobao
    on Jul 22, 2026 – with ChatGPT Codex Connector

    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:

    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.

  12. ASH1998 commented on Jul 22, 2026

    @ASH1998
    ASH1998
    on Jul 22, 2026
    Image

    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

  13. xuezchuang commented on Jul 22, 2026

    @xuezchuang
    xuezchuang
    on Jul 22, 2026 – with ChatGPT Codex Connector

    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.

  14. alreadyjust commented on Jul 22, 2026

    @alreadyjust
    alreadyjust
    on Jul 22, 2026

    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

  15. Dok11 commented on Jul 22, 2026

    @Dok11
    Dok11
    on Jul 22, 2026

    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

  16. Wado729 commented on Jul 22, 2026

    @Wado729
    Wado729
    on Jul 22, 2026

    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.

  17. Dok11 commented on Jul 22, 2026

    @Dok11
    Dok11
    on Jul 22, 2026

    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.

  18. Wado729 commented on Jul 22, 2026

    @Wado729
    Wado729
    on Jul 22, 2026

    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.

  19. xszaryx commented on Jul 22, 2026

    @xszaryx
    xszaryx
    on Jul 22, 2026

    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.

  20. dabroz commented on Jul 22, 2026

    @dabroz
    dabroz
    on Jul 22, 2026

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

  21. AmeenJalali commented on Jul 23, 2026

    @AmeenJalali
    AmeenJalali
    on Jul 23, 2026

    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

  22. Dok11 commented on Jul 23, 2026

    @Dok11
    Dok11
    on Jul 23, 2026

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

    Image

    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

  23. ValentinNikolaev commented on Jul 23, 2026

    @ValentinNikolaev
    ValentinNikolaev
    on Jul 23, 2026

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

  24. Dok11 commented on Jul 24, 2026

    @Dok11
    Dok11
    on Jul 24, 2026

    CPU peaks is much shorter today:

    Image

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformancewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions