High CPU Usage Triggered by Windows Defender & WMI When Launching Codex Desktop on Windows 10 #33875

Activity

1. ramisasa9080-blip

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jul 17, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   performance

   on Jul 17, 2026
3. github-actions commented on Jul 17, 2026

   

   github-actionsbot

   on Jul 17, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows 10] Unified ChatGPT app causes persistent Microsoft Defender CPU usage and system-wide mouse stuttering #33711

   Powered by Codex Action
4. adyshimony commented on Jul 17, 2026

   

   adyshimony

   on Jul 17, 2026

   More actions

   Happening all the time on my Win machine, Version 26.715.21425
   Every Codex app start, and every task start in Codex.

   This is a blocker, its taking all the cpu.

   👍React with 👍4Reacted by Kenny Vaneetvelde, Jalil-Mahdizadeh, Christopher James and JKLove
5. lordtd-hub commented on Jul 18, 2026

   

   lordtd-hub

   on Jul 18, 2026

   More actions

   I can confirm this issue still exists on Windows 11 with the latest desktop release 26.715.31251.

   I tested the following:

   ChatGPT Classic does not reproduce the issue.
   Opening Codex without opening any workspace immediately causes WMI Provider Host and Windows Management Instrumentation CPU usage to increase.
   Closing Codex immediately returns CPU usage to normal.
   winmgmt /verifyrepository reports "WMI repository is consistent".
   Microsoft Defender exclusions did not resolve the issue.

   This appears to affect at least Windows 10 and Windows 11.
6. lordtd-hub

   marked Windows: opening Codex causes sustained WMI Provider Host CPU usage and system stutter #33940 as a duplicate of this issue on Jul 18, 2026
7. d3nn3s08 commented on Jul 18, 2026

   

   d3nn3s08

   on Jul 18, 2026

   Last edited by d3nn3s08

   More actions

   I’m experiencing what appears to be the same issue on Windows 11.

   System:

   • Windows 11
   • AMD Ryzen 5 5600X (6 cores / 12 threads)
   • 32 GB RAM
   • NVIDIA GPU
   • Docker Desktop with WSL2 is running in the background

   When Codex is open, total CPU usage stays around 34–41%, even when no task is actively running. The mouse and the entire Windows interface begin to stutter.

   The following processes showed noticeable CPU usage:

   • Codex / ChatGPT
   • Antimalware Service Executable
   • WMI Provider Host

   After completely terminating Codex through Task Manager:

   • Total CPU usage immediately dropped from approximately 34% to 2%
   • RAM usage dropped from 16.6 GB to 11.2 GB
   • The mouse stuttering stopped
   • Docker Desktop and WSL2 remained running without causing any problems

   After launching Codex again, the CPU load immediately increased and the stuttering returned.

   This strongly suggests that Codex is triggering additional CPU activity in Microsoft Defender and WMI. The issue is reproducible after restarting Codex.

   I also captured and uploaded a performance trace while the issue was occurring.

   Feedback ID: 019f7532-b24d-7a53-899d-f973659191c4

   

   👍React with 👍3Reacted by Jannik N., Chuniqus and Udaiveer Singh Bhangu
8. CostanzoPadovano commented on Jul 19, 2026

   

   CostanzoPadovano

   on Jul 19, 2026 – with ChatGPT Codex Connector

   More actions

   I can confirm this on another Windows 11 system, with additional WMI/Delivery Optimization evidence.

   Environment

   • Windows 11 Pro 25H2, build 26200.8875
   • Microsoft Store/MSIX package: OpenAI.Codex 26.715.4045.0
   • ASUS PRIME Z890-P WIFI
   • Intel Core Ultra 7 265KF
   • Realtek RTL8125 2.5GbE, driver 1125.27.50.919 (current ASUS release)
   • WSL2 is enabled

   Observed behavior

   • After a clean reboot, launching the Windows ChatGPT/Codex desktop app triggers sustained WMI activity and visible CPU load.
   • A captured Task Manager sample showed approximately:
     • WMI Provider Host: 18.7%
     • Windows Management Instrumentation service: 8.1%
     • Antimalware Service Executable: 7.1%
     • ChatGPT: 2.9%
     • Total CPU: 48%
   • Running Codex from Ubuntu/WSL2 does not reproduce the issue.
   • Reinstalling the Store app did not prevent recurrence.

   WMI evidence
   The WMI Activity/Operational log recorded Event ID 5858 every ~2 seconds:

   ClientProcessId = <DoSvc PID>
   Operation = Start IWbemServices::ExecQuery - ROOT\StandardCimv2 :
   SELECT * FROM MSFT_NetAdapterStatisticsSettingData
   WHERE Name = 'Ethernet'
   ResultCode = 0x80041032
   

   The client PID consistently mapped to the Windows Delivery Optimization service (DoSvc). Temporarily stopping DoSvc immediately stopped the repeated NetAdapter WMI events and WMI CPU usage. DoSvc itself is configured normally as Automatic (Delayed Start).

   One captured occurrence overlapped a Store acquisition/reinstall:

   • 78 identical WMI errors from 12:41:52 to 12:44:22
   • Store downloaded 731,261,669 bytes for OpenAI.Codex
   • download completed at 12:43:24
   • installation completed successfully at 12:43:33
   • WMI errors stopped at 12:44:22
   • CPU settled several minutes later, likely including Defender/Search post-install work

   This suggests at least part of the Windows-specific CPU spike involves the Store/MSIX update path activating DoSvc, which then repeatedly queries NetAdapter statistics. The app/Store trigger and the WMI provider load may be overlapping aspects of the same regression.
9. suiyuebaobao commented on Jul 20, 2026

   

   suiyuebaobao

   on Jul 20, 2026

   More actions

   I can reproduce this on another Windows 11 x64 machine with the current Microsoft Store build, and the process breakdown is consistent with this issue.

   Environment

   • App package: OpenAI.Codex_26.715.4045.0_x64
   • Installation: Microsoft Store
   • OS: Windows 11 Pro x64, version 10.0.26100
   • CPU: Intel Core i9-13900HX, 24 physical cores / 32 logical processors
   • RAM: 32 GB
   • GPUs: Intel UHD Graphics + NVIDIA RTX 4080 Laptop GPU
   • Intel graphics driver loaded by the app GPU process: 31.0.101.4502

   Reproduction

   1. Fully restart the ChatGPT/Codex desktop app.
   2. Open a local Codex thread.
   3. Do not run a build, test suite, development server, browser automation, or other heavy workload.
   4. Sample the related processes for 10–15 seconds.

   The Codex CLI by itself does not reproduce the same CPU behavior.

   Measurements

   A 10.02-second sample produced the following values. “One-core %” treats one logical processor as 100%; “system %” is normalized across all 32 logical processors.

   Process group	One-core %	System %
   ChatGPT.exe	29.8%	0.93%
   WmiPrvSE.exe	15.6%	0.49%
   MsMpEng.exe	14.0%	0.44%
   bundled codex.exe	0.2%	~0%

   The combined value is approximately 59.6% of one logical CPU core (about 1.86% of the whole 32-thread system), which matches the user-visible ~60% reading.

   A separate 15-second sample of the desktop process tree after restart showed approximately:

   Desktop process	One-core %
   ChatGPT.exe main	30.1%
   GPU process	9.5%
   renderer	8.9%
   codex.exe app-server	1.4%
   Total	50.0%

   The previous launch produced essentially the same result: 51.1% of one core. Restarting did not materially change it.

   Additional observations

   • The hot path is not the Codex app-server alone; the Electron/ChatGPT main, GPU, and renderer processes contribute most of the app-owned CPU.
   • WMI Provider Host and Microsoft Defender are also active during the same sampling window.
   • The GPU process loads the Intel D3D driver rather than the NVIDIA driver.
   • Changing the Windows per-app GPU preference did not change adapter selection or materially change CPU use, so that test setting was reverted.
   • No newer Store package was available at the time of testing.
   • I have not attached raw desktop logs because they may contain local paths or session metadata, but I can provide a sanitized summary if maintainers need it.

   Expected behavior: when there is no build/test/browser workload, the desktop shell and its WMI/Defender side effects should settle close to idle instead of continuously consuming roughly half of a logical CPU core.

   👍React with 👍2Reacted by Hristo Kozhuharov and Udaiveer Singh Bhangu
10. matthewdm0816 commented on Jul 20, 2026

    

    matthewdm0816

    on Jul 20, 2026

    More actions

    I found that the high CPU usage (both ChatGPT/Codex, and WMIProvider) can be triggered, if you hover your mouse on the (projects) sidebar, and move quickly up and down.

    👍React with 👍1Reacted by Hristo Kozhuharov
11. ShiftZ commented on Jul 20, 2026

    

    ShiftZ

    on Jul 20, 2026

    Last edited by ShiftZ

    More actions

    I have the same issue. Constant WMI and Antimalware CPU activity while Codex is open.

    👍React with 👍2Reacted by greydesolate and exnihilo21
12. huanxuan123 commented on Jul 20, 2026

    

    huanxuan123

    on Jul 20, 2026

    More actions

    This looks related to #34014, although it may not have exactly the same trigger.

    The important difference is that this issue reproduces on the Home screen without opening a repository, while my reproduction required opening a repository with a very large dirty working tree. The existing report that rapidly hovering over projects in the sidebar can trigger the problem also suggests that project/sidebar metadata refresh may be another entry point.

    In my reproduction, WMI Provider Host and Defender were downstream effects rather than the original workload. The standalone app continuously created and cancelled short-lived Git processes:

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

    The parent was the main ChatGPT.exe process. Repeated commands included git config, git hash-object, per-file git diff, and taskkill /t /f.

    Reducing the repository from 2,286 untracked files to 10 stopped the process storm:

    • New git.exe processes: 0
    • New taskkill.exe processes: 0
    • WMI CPU: ~39% → 0.6%
    • Defender CPU: ~8% → 0.3%

    Full process-level evidence and the workaround are documented here:

    #34014 (comment)

    This suggests there may be at least two standalone-app triggers:

    1. Home/project-sidebar metadata refresh.
    2. Changes/Review live-query refresh for large dirty working trees.

    Both may share the same underlying problem: refreshes are not sufficiently coalesced or debounced, causing repeated local process creation and cancellation. It may be useful to instrument Git worker invocations, child-process creation rate, and sidebar/project metadata refresh separately.

    👍React with 👍2Reacted by Udaiveer Singh Bhangu and Dick Kimberlin
13. q447552640 commented on Jul 21, 2026

    

    q447552640

    on Jul 21, 2026

    More actions

    If I launch Codex Desktop directly in user mode, it spawns a large number of terminal processes and keeps failing repeatedly, with up to five or six hundred such processes running. Meanwhile, the WMI Provider Host process consumes over 50% of system resources. However, when I run it as administrator, no excessive terminal processes are created and WMI operates normally. This issue is most likely caused by a permission-checking process that keeps failing and restarting continuously.
    Right Click Codex And Run As Administrator may be helpful.

    👍React with 👍1Reacted by Dr. Derek Austin
14. RenishSkills commented on Jul 21, 2026

    

    RenishSkills

    on Jul 21, 2026

    More actions

    I’m experiencing the same problem with Codex Desktop 26.715.61943. There are too many git.exe and taskkill.exe processes, and WMI Provider Host consumes over 80% of the CPU, making the system unusable.
    Running as Administrator didn’t help me.
    The high CPU usage begin when I open an existing chat or conversation. I believe it dies in reading old conversation especially when it is large.

    I’ve switched back to Codex CLI, which works without any issues.
15. suiyuebaobao commented on Jul 22, 2026

    

    suiyuebaobao

    on Jul 22, 2026 – with ChatGPT Codex Connector

    More actions

    I was able to stop the process storm on my machine with a practical Windows workaround.

    In my reproduction, WMI Provider Host and Microsoft Defender were downstream effects. The Codex desktop app was continuously creating and cancelling short-lived Git processes:

    • 247 new git.exe processes per 10 seconds
    • 137 new taskkill.exe processes per 10 seconds
    • 259 new conhost.exe processes per 10 seconds

    I now launch the original Microsoft Store/MSIX Codex app with a process-scoped GIT_DIR=NUL. After startup stabilized, a 15-second trace recorded:

    • 0 new git.exe processes
    • 0 new taskkill.exe processes
    • WMI Provider Host: about 6.6% → 0.9%
    • Microsoft Defender: about 5.9% → 2.6% and falling

    I published the single-file launcher and bilingual documentation here:

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

    Usage: fully exit Codex from the Windows system tray, then run Codex-Git-Disabled.cmd.

    This is an unofficial workaround rather than an upstream fix. The trade-off is that Review, Changes, branch detection, commit, and other Git-backed Codex features will be unavailable or incomplete. The script does not patch the Codex installation, modify repositories or Git configuration, write system environment variables, require elevation, terminate processes, or remove chat history. Launching Codex normally restores its Git integration.

    👍React with 👍3Reacted by suiyuebaobao, Kazami Michiru and NextArcadia
16. elpicio commented on Jul 22, 2026

    

    elpicio

    on Jul 22, 2026

    Last edited by elpicio

    More actions

    I found an additional trigger that may help narrow down the cause.

    Environment

    • Windows 10 Pro 22H2
    • Codex Desktop 26.715.10079.0
    • Microsoft Store installation
    • Microsoft Defender real-time protection enabled
    • Native Windows Codex CLI available for comparison

    Additional observations

    I saw the same relationship between the active UI route and WMI load:

    • Home, New Chat, conversation, or Review view: WmiPrvSE.exe and MsMpEng.exe CPU usage increased.
    • Settings view: WMI usage stopped almost immediately.
    • Existing Codex tasks continued running while Settings was open.
    • The native Windows CLI did not reproduce the abnormal WMI load.

    I then found that a large dirty Git working tree was a strong trigger in my environment.

    During the affected period, the Codex Desktop logs recorded:

    • 373 Git commands
    • 362 commands with requestKind=review-summary
    • 241 git hash-object commands
    • 116 git diff commands
    • 360 commands marked as aborted
    • A peak of 58 Git commands in one minute

    Typical commands included:

    git diff
    git diff --no-index /dev/null <untracked-file>
    git hash-object <file>
    

    Many of the affected files were untracked images, screenshots, WebP files, documents, and source files.

    The review baseline covered 1,066 changed files, including 277 binary files. The final set of commits that made the
    working tree mostly clean contained 185 files and 12 binary files.

    After committing those changes, the abnormal WMI and Defender usage stopped. The Codex Desktop version remained
    unchanged, so this was not caused by an application update.

    Possible mechanism

    Based on the Desktop logs, the behavior appears to involve two interacting paths:

    Large dirty working tree
    → review-summary repeatedly recalculates diffs and file hashes
    → previous calculations are cancelled and restarted
    → many short-lived Git and PowerShell processes
    → Desktop samples the changing process tree through WMI
    → WmiPrvSE CPU usage increases
    → Defender scans the processes and files being read
    → MsMpEng CPU usage increases as a secondary effect

    This also explains why the issue can occur on the Home or New Chat screen without explicitly opening a repository.
    Those views still load project, thread, repository, and review-related state. Settings does not appear to keep those
    components active.

    I found no actual gh.exe invocation in the logs. Entries labeled gh-pr-status only executed a small number of git
    config --get remote.upstream.url commands, so GitHub CLI does not appear to be involved.

    Suggested test for other affected users

    1. Check known repositories and Codex worktrees with git status --short.
    2. Commit or stash large pending changes.
    3. Ignore generated screenshots, logs, and build artifacts when appropriate.
    4. Restart Codex Desktop and compare Home/New Chat with Settings.
    5. Check %LOCALAPPDATA%\Codex\Logs for repeated requestKind=review-summary, git diff, and git hash-object entries.

    This may not explain every clean-install or empty-repository reproduction. The dirty working tree appears to be a
    trigger or amplifier, while the underlying issue is likely the Desktop review refresh and WMI process-sampling
    behavior.

    Potential improvements may include debouncing review-summary refreshes, allowing only one calculation per repository,
    avoiding immediate restarts after cancellation, and avoiding full WMI process enumeration during frequent UI state
    updates.
17. Jalil-Mahdizadeh commented on Jul 23, 2026

    

    Jalil-Mahdizadeh

    on Jul 23, 2026

    More actions

    I can reproduce this consistently on another Windows system, with a controlled Desktop-open/Desktop-closed comparison.

    Environment

    • Codex Desktop: 26.715.10079.0 (Microsoft Store/MSIX)
    • Windows: 25H2, build 26200.8894
    • CPU: Intel Core Ultra 9 285H (16 cores / 16 logical processors)
    • RAM: 64 GB

    Controlled A/B result

    1. Fully exit Codex Desktop: total CPU settles at 2.6–3%; WmiPrvSE.exe is about 1%.
    2. Launch Codex Desktop and leave it idle: Task Manager holds around 47–50% (and direct performance-counter samples reached 70–75%); the laptop fan remains continuously active.
    3. Fully exit Codex Desktop again: CPU immediately returns to about 3%.

    The separate native Codex CLI remained open during this comparison and did not reproduce the load, so the trigger is specifically the Desktop app lifecycle.

    Task Manager's per-logical-processor view shows 14 of 16 processors heavily active, with only the two low-power cores near idle.

    Counters captured while affected

    • Processor Time: 74.6% average
    • Processor Utility: 95.4% average
    • Privileged Time: 50.7% average
    • DPC Time: 0.4%
    • Interrupt Time: 1.0%
    • WmiPrvSE.exe: 24.3%
    • svchost.exe hosting Winmgmt: 8.5%
    • MsMpEng.exe: 7.9%

    Docker containers were below 0.2% combined, and no WSL distribution was installed. This strongly supports WMI and Defender being downstream effects; opening Codex Desktop is the strict trigger. This is severe enough to cause sustained fan noise, heat, battery drain, and makes leaving the desktop client open impractical.

    👍React with 👍3Reacted by Jalil-Mahdizadeh, exnihilo21 and NextArcadia
18. mtharrington commented on Jul 23, 2026

    

    mtharrington

    on Jul 23, 2026

    More actions

    Also experiencing the same issues Windows 11:

    Constant jump in WMI and Antimalware. Especially with the Delivery Optimization service. And a large number of hanging terminate process commands. It's making it almost unusable.

    👍React with 👍4Reacted by exnihilo21, Aitor Andreu, Ryan Stolliker and NextArcadia
19. TnzGit commented on Jul 24, 2026

    

    TnzGit

    on Jul 24, 2026

    More actions

    I can reproduce this consistently on Windows with Codex Desktop 26.715.10079.0.

    A controlled Codex-off/Codex-on A/B test showed:

    • Codex absent for 765 one-second frames:
      • system CPU average: 34.2%
      • scheduler heartbeat P95: 36.4 ms
    • Codex present for 261 frames:
      • system CPU average: 45.9%
      • scheduler heartbeat P95: 64.1 ms

    Completely exiting Codex immediately made the desktop and mouse smooth.
    Reopening Codex immediately brought the stuttering back.

    Native process capture showed ChatGPT.exe repeatedly spawning PowerShell commands containing:

    • Get-CimInstance Win32_Process
    • Get-CimInstance Win32_PerfFormattedData_PerfProc_Process

    WMI Analytic Trace linked those calls to CIMWin32/WmiPrvSE.

    Read-only inspection of resources/app.asar located the Windows implementation in:

    • .vite/build/child-process-snapshot-worker.js
    • .vite/build/main-BYnIDJ6m.js

    The current package does not appear to expose a user setting or feature flag for disabling this sampler.

    Physical C: disk latency and queue remained low, while DWM and other major applications were nearly unchanged across the A/B test.

    I have a sanitized investigation report and PDH/heartbeat evidence available if maintainers need it.
20. tkniley commented on Jul 24, 2026

    

    tkniley

    on Jul 24, 2026

    More actions

    Whatever opening the settings page does to reduce the cpu usage, please implement that.
21. 5168413518 commented on Oct 8, 2026

    

    5168413518

    on Oct 8, 2026 – with ChatGPT Codex Connector

    More actions

    Sharing a specific, verified cause of high idle CPU/heat on Windows 10. In this case the hot child processes were Git probes against an unintended parent Git repository; I did not measure the WMI/Defender root causes reported by others.

    Confirmed Windows 10 workaround: accidental Git repo at %USERPROFILE% was causing idle Codex Git scans

    I 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

    • The main ChatGPT.exe was launching repeated git.exe subprocesses. One captured command was git ... ls-files --cached -z -- AppData/Local/Packages/....
    • Five distinct short-lived Git PIDs appeared in ~2.5 seconds.
    • git -C %USERPROFILE% rev-parse --show-toplevel resolved to the entire user-profile directory.
    • An unintended %USERPROFILE%\.git existed (with HEAD / 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.
    • A separate real development repository on another drive had its own .git and was unaffected.

    Reversible workaround that worked here

    1. Verify whether %USERPROFILE%\.git is actually needed. Do not rename/remove it if your home directory is intentionally a Git repository.
    2. Fully exit ChatGPT/Codex desktop (including background/tray processes).
    3. Back up/rename only that unneeded ancestor repo from %USERPROFILE%\.git to a timestamped .git_backup_YYYY-MM-DD; do not delete it.
    4. Restart the app. Verify the home folder is no longer a Git worktree, then verify each actual development repository still resolves to its own Git root.

    After: 0 git.exe PIDs 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)