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

Open 💬 9 comments Opened Jul 17, 2026 by ramisasa9080-blip

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Codex Desktop Version: 26.715.2305.0

What subscription do you have?

pro 20x

What platform is your computer?

windows

What issue are you seeing?

High CPU Usage Triggered by Windows Defender & WMI When Launching Codex Desktop on Windows 10
Environment
OS: Windows 10 Pro x64
CPU: Intel Core i5-10400F
RAM: 16 GB
GPU: NVIDIA GTX 1650
Codex Desktop Version: 26.715.2305.0
Installation: Microsoft Store
Summary

Launching Codex Desktop immediately causes extremely high CPU usage, even before opening any project.

The CPU reaches 90–100% due to the combination of:

ChatGPT / Codex processes
Windows Defender (Antimalware Service Executable)
WMI Provider Host (WmiPrvSE.exe)

This significantly increases CPU temperature and system load.

Expected Behavior

Opening Codex Desktop without opening any project should result in minimal CPU usage (similar to VS Code extension).

Actual Behavior

Immediately after launching Codex Desktop:

CPU usage jumps to 90–100%.
Windows Defender starts consuming 20–40% CPU.
WMI Provider Host also starts consuming 10–20% CPU.
CPU temperature increases accordingly.

This happens even while sitting on the Home screen without opening any workspace.

Troubleshooting Performed

I tested all of the following:

✅ Replaced CPU thermal paste.
✅ Verified CPU cooler installation.
✅ Tested CPU temperatures (hardware is working normally).
✅ Added Windows Defender exclusions for:
Project folder
C:\Users\<user>\AppData\Local\OpenAI
...\Codex\runtimes
✅ Restarted Windows.
✅ Disabled Windows Defender Real-time Protection.
✅ Tested without opening any project.
✅ Tested after removing NVIDIA RTX Voice.
✅ Checked WMI logs.
✅ Rebuilt Windows Performance Counters.
✅ Verified CPU is normal outside Codex.

None of these resolved the issue.

Important Observation

When Real-time Protection is disabled:

Windows Defender CPU usage disappears.
Codex CPU usage increases instead.

This suggests Defender is scanning Codex activity rather than being the original source.

Comparison with VS Code

Using the Codex extension inside VS Code:

CPU usage remains around 40–70%
No abnormal Defender behavior.
Much lower overall system load.

Only Codex Desktop reproduces this issue.

WMI Activity

Windows Event Viewer shows continuous WMI queries such as:

Win32_Processor
Win32_OperatingSystem
Win32_PerfFormattedData_PerfProc_Process

WMI Provider Host becomes active immediately after launching Codex Desktop.

Additional Notes

The issue occurs:

without opening any project
after reboot
with Defender exclusions configured
even on the Home screen

This suggests the desktop application itself is triggering excessive background activity that causes Defender and WMI to become heavily active.

Request

Could the team investigate whether the current Windows Desktop build performs excessive background indexing, WMI queries, or runtime initialization that triggers Microsoft Defender?

The behavior appears specific to Codex Desktop, since the VS Code extension does not reproduce the same level of CPU usage.

What steps can reproduce the bug?

Launching Codex Desktop immediately causes extremely high CPU usage, even before opening any project.

The CPU reaches 90–100% due to the combination of:

ChatGPT / Codex processes
Windows Defender (Antimalware Service Executable)
WMI Provider Host (WmiPrvSE.exe)

This significantly increases CPU temperature and system load.

Expected Behavior

Opening Codex Desktop without opening any project should result in minimal CPU usage (similar to VS Code extension).

Actual Behavior

Immediately after launching Codex Desktop:

CPU usage jumps to 90–100%.
Windows Defender starts consuming 20–40% CPU.
WMI Provider Host also starts consuming 10–20% CPU.
CPU temperature increases accordingly.

This happens even while sitting on the Home screen without opening any workspace.

Troubleshooting Performed

I tested all of the following:

None of these resolved the issue.

Important Observation

When Real-time Protection is disabled:

Windows Defender CPU usage disappears.
Codex CPU usage increases instead.

This suggests Defender is scanning Codex activity rather than being the original source.

Comparison with VS Code

Using the Codex extension inside VS Code:

CPU usage remains around 40–70%
No abnormal Defender behavior.
Much lower overall system load.

Only Codex Desktop reproduces this issue.

WMI Activity

Windows Event Viewer shows continuous WMI queries such as:

Win32_Processor
Win32_OperatingSystem
Win32_PerfFormattedData_PerfProc_Process

WMI Provider Host becomes active immediately after launching Codex Desktop.

Additional Notes

The issue occurs:

without opening any project
after reboot
with Defender exclusions configured
even on the Home screen

This suggests the desktop application itself is triggering excessive background activity that causes Defender and WMI to become heavily active.

Request

Could the team investigate whether the current Windows Desktop build performs excessive background indexing, WMI queries, or runtime initialization that triggers Microsoft Defender?

The behavior appears specific to Codex Desktop, since the VS Code extension does not reproduce the same level of CPU usage.

What is the expected behavior?

_No response_

Additional information

Launching Codex Desktop immediately causes extremely high CPU usage, even before opening any project.

The CPU reaches 90–100% due to the combination of:

ChatGPT / Codex processes
Windows Defender (Antimalware Service Executable)
WMI Provider Host (WmiPrvSE.exe)

This significantly increases CPU temperature and system load.

Expected Behavior

Opening Codex Desktop without opening any project should result in minimal CPU usage (similar to VS Code extension).

Actual Behavior

Immediately after launching Codex Desktop:

CPU usage jumps to 90–100%.
Windows Defender starts consuming 20–40% CPU.
WMI Provider Host also starts consuming 10–20% CPU.
CPU temperature increases accordingly.

This happens even while sitting on the Home screen without opening any workspace.

Troubleshooting Performed

I tested all of the following:

None of these resolved the issue.

Important Observation

When Real-time Protection is disabled:

Windows Defender CPU usage disappears.
Codex CPU usage increases instead.

This suggests Defender is scanning Codex activity rather than being the original source.

Comparison with VS Code

Using the Codex extension inside VS Code:

CPU usage remains around 40–70%
No abnormal Defender behavior.
Much lower overall system load.

Only Codex Desktop reproduces this issue.

WMI Activity

Windows Event Viewer shows continuous WMI queries such as:

Win32_Processor
Win32_OperatingSystem
Win32_PerfFormattedData_PerfProc_Process

WMI Provider Host becomes active immediately after launching Codex Desktop.

Additional Notes

The issue occurs:

without opening any project
after reboot
with Defender exclusions configured
even on the Home screen

This suggests the desktop application itself is triggering excessive background activity that causes Defender and WMI to become heavily active.

Request

Could the team investigate whether the current Windows Desktop build performs excessive background indexing, WMI queries, or runtime initialization that triggers Microsoft Defender?

The behavior appears specific to Codex Desktop, since the VS Code extension does not reproduce the same level of CPU usage.

View original on GitHub ↗

9 Comments

github-actions[bot] contributor · 3 days ago

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

#33711

Powered by Codex Action

adyshimony · 3 days ago

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.

lordtd-hub · 2 days ago

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.

d3nn3s08 · 2 days ago

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

CostanzoPadovano · 1 day ago

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.

suiyuebaobao · 1 day ago

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

Fully restart the ChatGPT/Codex desktop app.
Open a local Codex thread.
Do not run a build, test suite, development server, browser automation, or other heavy workload.
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.

matthewdm0816 · 22 hours ago

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.

ShiftZ · 15 hours ago

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

huanxuan123 · 8 hours ago

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:

Home/project-sidebar metadata refresh.
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.