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

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

• #33711

Powered by Codex Action

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.

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.

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

<img width="733" height="592" alt="Image" src="https://github.com/user-attachments/assets/fadacb33-2bb8-4649-be14-b37109dbd753" />

<img width="756" height="592" alt="Image" src="https://github.com/user-attachments/assets/f690e3c8-a3fc-4af0-9598-70cbb21084ba" />

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.

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.

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.

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

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:

https://github.com/openai/codex/issues/34014#issuecomment-5026272173

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.

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.

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.

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.

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:

``text
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.

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.

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.

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.

Whatever opening the settings page does to reduce the cpu usage, please implement that.