[Windows][26.715.8383.0] Desktop app appears to trigger sustained WMI/Defender CPU usage that stops immediately on full app exit

Open 💬 2 comments Opened Jul 22, 2026 by DiegohEh
💡 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?

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.exe process 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:

  1. While the machine was stuck in the sustained high-CPU state, I fully exited the desktop app using its system-tray Quit/Exit action.
  2. CPU usage dropped abruptly to approximately 5% at the exact moment the app exited.
  3. The fans became quiet immediately.
  4. The same WmiPrvSE.exe process remained alive, but its measured CPU usage fell from approximately 11-15% of total system CPU to approximately 0.7%.
  5. 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:

  1. Launch the unified ChatGPT/Codex desktop app on Windows.
  2. Use it normally for several hours, including opening or switching between conversations/tasks.
  3. Leave the app open even when no visible task is running.
  4. Observe the laptop fans, system responsiveness, and Task Manager.
  5. When the issue occurs, note sustained CPU from WMI Provider Host, the WMI service host, and Microsoft Defender.
  6. Fully exit ChatGPT/Codex from the system-tray icon, not only by closing its window.
  7. Observe CPU and fan activity drop immediately.
  8. 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, PID 8056
  • 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.exe PID 25896, 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.0 at 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

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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34594
  • #34592
  • #34580

Powered by Codex Action

onovich · 1 month ago

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.