[Windows][26.715.8383.0] Desktop app appears to trigger sustained WMI/Defender CPU usage that stops immediately on full app exit
What version of the Codex App are you using?
OpenAI.Codex_26.715.8383.0_x64 (the new unified ChatGPT/Codex Windows desktop app)
The running executable is ChatGPT.exe, product version 150.0.7871.124.
What subscription do you have?
Pro
What platform are you using?
- Windows 11 Home 25H2, build
26200.8875, x64 - AMD Ryzen 7 7435HS, 16 logical processors
- Lenovo LOQ laptop
What issue are you seeing?
After the unified ChatGPT/Codex desktop app has been open and used for some time, the system can enter an apparently idle but sustained high-CPU state. The laptop fans run continuously and the entire desktop occasionally stutters, including mouse movement, even though no visible Codex/ChatGPT task is running.
Task Manager attributes most of the CPU usage to Windows components rather than directly to ChatGPT.exe:
WMI Provider Host/WmiPrvSE.exe: approximately 12-21% total CPU- Windows Management Instrumentation service host: approximately 7%
- Microsoft Defender (
Antimalware Service Executable): approximately 8% ChatGPT.exeprocess group: approximately 3-10%, depending on the sample- Observed total CPU: approximately 38-59%, with other monitoring tools sometimes showing higher short peaks
The strongest reproduction evidence is a controlled app lifecycle test:
- While the machine was stuck in the sustained high-CPU state, I fully exited the desktop app using its system-tray Quit/Exit action.
- CPU usage dropped abruptly to approximately 5% at the exact moment the app exited.
- The fans became quiet immediately.
- The same
WmiPrvSE.exeprocess remained alive, but its measured CPU usage fell from approximately 11-15% of total system CPU to approximately 0.7%. - Reopening the desktop app produced a short startup spike, after which the machine remained quiet again.
This suggests that app shutdown releases or cancels a background workload involving WMI/Defender. It does not appear to require terminating the WMI process itself.
Steps to reproduce
The issue is intermittent rather than immediately deterministic:
- Launch the unified ChatGPT/Codex desktop app on Windows.
- Use it normally for several hours, including opening or switching between conversations/tasks.
- Leave the app open even when no visible task is running.
- Observe the laptop fans, system responsiveness, and Task Manager.
- When the issue occurs, note sustained CPU from
WMI Provider Host, the WMI service host, and Microsoft Defender. - Fully exit ChatGPT/Codex from the system-tray icon, not only by closing its window.
- Observe CPU and fan activity drop immediately.
- Reopen the app. A brief startup spike may occur, but CPU returns to normal.
Conversation/task switching has triggered short system-wide stutters and has sometimes preceded a CPU episode, but the high-CPU state can also begin without an obvious foreground action.
Expected behavior
When no ChatGPT/Codex task is actively running, the desktop app and any Windows services it invokes should return to a bounded idle state. Closing or switching a conversation should not leave WMI providers, Defender, Git/workspace watchers, update checks, or other background integrations consuming sustained CPU.
Actual behavior
The app can enter or trigger a background state in which Windows WMI and Defender remain CPU-active indefinitely. Fully exiting the app immediately clears the state; reopening it resets the behavior temporarily.
Diagnostic evidence
A low-impact resident monitor and Windows performance counters were used during the affected period.
- Hot WMI host:
WmiPrvSE.exe, PID8056 - Measured hot-host CPU: approximately 11-15% of total system CPU over repeated samples
- After full ChatGPT/Codex exit: the same PID dropped to approximately 0.68-0.78%
- WMI Activity Operational events showed
svchost.exePID25896, mapped to Delivery Optimization (DoSvc), repeatedly issuing failed queries:
Namespace: ROOT\StandardCimv2
Query: SELECT * FROM MSFT_NetAdapterStatisticsSettingData WHERE Name = 'Wi-Fi'
ResultCode: 0x80041032
Client: DoSvc (svchost.exe)
Two bursts were recorded on 2026-07-21:
21:37:53-21:39:01: 37 failed queries
22:47:23-22:48:52: 47 failed queries
Median interval: approximately 2.04 seconds
The hot WMI PID remained at approximately 11-14% CPU for at least 18 minutes after the last recorded DoSvc query. Delivery Optimization also had multiple Microsoft-hosted downloads in cache. Therefore DoSvc may be part of the trigger chain, but the exact provider or background app subsystem responsible has not been proven.
At desktop-app restart time, WMI logged short-lived queries for processor virtualization and hypervisor state, followed by a return to low CPU.
Microsoft Defender appears to amplify the episode, but disabling Defender was not attempted and is not proposed as a workaround.
Timeline and version correlation
- The machine did not exhibit this behavior before the Codex/ChatGPT desktop app was installed and used.
- The problem has been observed intermittently since installing the app approximately one week earlier.
- The package updated to
26.715.8383.0at approximately 10:24 local time on 2026-07-21. - The first captured CPU episode after that update began at approximately 10:25.
- The conclusive full-exit test was performed at approximately 23:11; the app was relaunched at approximately 23:12.
The timing is correlation, not proof that the package update itself introduced the underlying bug.
What was ruled out or kept separate
- RAM pressure was intentionally excluded from this investigation.
- The reproduction evidence and timing correlation point specifically to the ChatGPT/Codex desktop app as the trigger for the episode.
- Exiting OneDrive did not stop the affected episode.
- The active workspace was not inside the OneDrive synchronization directory.
- No WMI repository rebuild, Defender disablement, service deletion, or other invasive system modification was performed.
Possibly related reports
- #20933 - Windows desktop app triggers heavy background Git work when opening a project/chat.
- #20735 - Codex can become stuck in a high-CPU idle state after extended use.
- Community report from 2026-07-21: https://www.reddit.com/r/codex/comments/1v2y2ug/chatgptcodex_desktop_app_started_using_100_cpu/ (another Windows user specifically reports
WMI Provider Hostmaxing out).
These reports overlap in symptoms but do not document the same WMI/Defender lifecycle evidence.
Additional information
I can collect additional sanitized diagnostics if maintainers specify which desktop-app logs, WMI trace providers, or performance recordings would be most useful. Because desktop logs may include local paths or conversation metadata, I would prefer guidance on the minimum files/fields required before uploading raw logs publicly.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I published a Windows-first community diagnostic skill that may help capture and classify this intermittent high-CPU state:
https://github.com/onovich/fix-codex-lag.skill
FixCodexLag uses a bounded snapshot and explicitly separates observed, correlated, and inferred findings. It checks whether taskkill/conhost/Git-helper churn or retained Codex runtime trees are present behind the WMI/Defender load, then reports confirmed / not detected / inconclusive.
It can also run an opt-in diagnosis-only monitor to catch intermittent recurrences; scheduled runs never repair automatically.
Because this issue has not yet established the exact provider or background subsystem responsible, this should be treated as a diagnostic and temporary-containment aid—not as proof of the root cause or a fix for every WMI/Defender episode.