[Windows app] Process Manager polling causes ~12–15 taskkill.exe launches/sec and sustained 40–50% CPU at idle

Summary

On the Windows ChatGPT/Codex desktop app, simply launching the app causes sustained system-wide CPU usage of approximately 40–50%, even when no agent work is running. CPU returns to normal immediately after fully quitting the app.

Local tracing shows that the desktop app's main process continuously launches roughly 12–15 taskkill.exe processes per second. At the same time, Windows WMI (Winmgmt / WmiPrvSE, CIMWin32 provider) and Microsoft Defender consume most of the CPU. The ChatGPT process group itself accounts for only a small portion of the total load.

This appears to be caused by the Process Manager / live PID polling path on Windows rather than by project code, a particular conversation, or a genuinely running child process.

Environment

• App: ChatGPT/Codex Windows desktop app, Microsoft Store/MSIX
• Package version: 26.715.10079.0
• Bundled Codex CLI: 0.145.0-alpha.30
• OS: Windows 11 Home 25H2, build 26200.8875, x64
• CPU: Intel Core i7-13705H (20 logical processors)
• App configuration: native Windows execution, windows.sandbox = "elevated"

Steps to reproduce

1. Ensure the ChatGPT/Codex desktop app is fully closed.
2. Observe normal/low CPU usage in Task Manager.
3. Launch the desktop app.
4. Do not start an agent task or command.
5. Observe system CPU rise to approximately 40–50%, with several logical cores near 90%.
6. Fully quit the desktop app.
7. Observe CPU immediately return to normal.

The behavior is reproducible on every launch.

Expected behavior

When the app is idle, background process monitoring should use negligible CPU and should not continuously create process-termination helpers.

Actual behavior

• Total CPU remains around 40–50% while the app is open.
• Winmgmt and WmiPrvSE are the main consumers, with additional Defender overhead.
• The ChatGPT main process continuously creates commands shaped like:

C:\Windows\System32\taskkill.exe /pid <pid> /t /f

• Direct process-start sampling observed:
• 226 taskkill.exe launches in 15 seconds (~15/sec)
• 90 launches in 6 seconds after a clean app restart (~15/sec)
• 71 launches in 6 seconds after killing and respawning the active renderer (~12/sec)

Diagnostic evidence

WMI activity

During the issue:

• Winmgmt service host consumed approximately 18% of total system CPU.
• WmiPrvSE consumed approximately 6.7% of total system CPU.
• WMI performance counters identified the CIMWin32 provider as active.
• WMI operational events around app startup included cancelled queries (0x80041032), including Win32_ComputerSystem, Win32_Processor, Win32_Process, and related classes.

Inspection of the shipped desktop bundle shows that the Windows process inventory path invokes PowerShell/CIM queries including Win32_PerfFormattedData_PerfProc_Process and Win32_Process. Process-tree cleanup uses taskkill.exe /pid ... /t /f.

The renderer also contains a Process Manager live-PID query (chat-process-live-pids) on a two-second interval behind feature gate 3264431617. With many command records/components present, these checks appear to multiply and keep the WMI/cleanup path continuously active.

Process registry reset

The local Process Manager registry contained stale completed command records. It was backed up and reset to an empty JSON array. After fully restarting the app:

• the registry remained empty;
• the taskkill.exe storm continued at approximately 15 launches/sec.

Therefore stale registry entries are not the root cause.

Conversation isolation

The app was temporarily navigated from the affected conversation to an almost empty test conversation. The rate remained approximately 70 taskkill.exe launches per six seconds. This rules out corruption in one particular conversation.

Renderer isolation

The active --type=renderer ChatGPT subprocess was force-terminated as a controlled test. The app automatically spawned a new renderer, but the storm continued unchanged (71 taskkill.exe processes in six seconds). Killing the renderer therefore does not mitigate the issue.

Sandbox checks

Changing the sandbox mode was not used as a workaround. A standalone test of both elevated and unelevated native Windows sandbox modes failed with CreateRestrictedToken failed: 87, so weakening or changing sandbox protection did not appear justified and would not address the Electron Process Manager polling path.

Workarounds tried

• Fully restart the desktop app: no improvement.
• Reset Process Manager registry after making a backup: no improvement.
• Navigate to an empty conversation: no improvement.
• Kill only the active renderer subprocess: renderer respawns; no improvement.
• Verify current MSIX update registration: package 26.715.10079.0 installed successfully; no newer locally staged package was found.

The only reliable workaround is to fully quit the desktop app, which makes local Codex desktop workflows unavailable.

Related issue

This may overlap with #22393, which documents Windows taskkill handling and an event/process storm across the extension and desktop app. However, this report is specifically about deterministic idle CPU load in the Windows desktop app, repeated WMI/CIM process inventory polling, and approximately 12–15 taskkill.exe launches per second.

Suggested investigation areas

• Coalesce chat-process-live-pids requests across rendered command items instead of polling per component.
• Stop polling when the Process Manager UI or relevant task is not visible.
• Cache one process inventory snapshot for all consumers over a longer interval.
• Avoid launching separate PowerShell/CIM queries and taskkill.exe helpers for already-exited or unmatched PIDs.
• Back off or disable Process Manager monitoring for the session after repeated WMI cancellation/access errors.
• Provide a user-visible switch to disable Process Manager monitoring on Windows until the issue is fixed.