Windows Desktop: Codex causes sustained WMI Provider Host high CPU usage

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

26.715.8383.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 11 25H2, build 26200.8875)

What issue are you seeing?

Summary

Codex Desktop on Windows entered an unbounded local execution-host cleanup storm. The main packaged ChatGPT.exe process repeatedly spawned taskkill.exe /pid <pid> /t /f. Those helpers repeatedly enumerated Win32_Process, driving the CIMWin32 WMI provider host to 53–61% whole-machine CPU and making Windows visibly sluggish.

This is related to #34260, but this report provides an independent reproduction on 26.715.8383.0, a provider-level ETW capture, parent-process attribution, packaged-app call-site confirmation, and a controlled full-restart comparison.

User-visible impact

• Task Manager showed one WMI Provider Host at 61.1% CPU.
• Hundreds of entries appeared with the localized description “End Process” (taskkill.exe).
• Ordinary local commands became increasingly slow.
• The load ended only after fully exiting and restarting Codex Desktop.

Provider-level evidence

A threshold-triggered WMI Trace capture started when WmiPrvSE.exe PID 8156 reached 53.05% CPU.

Over approximately 12 seconds, the capture contained:

• 2,509 WMI Trace events
• 254 client ExecQuery operations
• 254 corresponding provider executions
• Hot provider: CIMWin32/cimwin32.dll
• Repeated query:

SELECT __PATH, ProcessId, CSName, Caption, SessionId, ThreadCount,
       WorkingSetSize, KernelModeTime, UserModeTime, ParentProcessId
FROM Win32_Process

The short-lived clients issuing these queries were taskkill.exe processes.

Process-parent evidence

A separate non-WMI native process sampler observed the following over 20 seconds:

| Measurement | Result |
|---|---:|
| New taskkill.exe processes | 410 |
| Direct children of Codex main ChatGPT.exe | 408 (99.5%) |
| Observed creation rate | 20.4/sec |
| Command shape | taskkill.exe /pid <pid> /t /f |

Failure-chain visualization

flowchart LR
    A["Concurrent local commands / tasks"] --> B["Codex execution-host cleanup"]
    B --> C["taskkill.exe /pid ... /t /f<br/>20.4 launches/sec"]
    C --> D["Repeated full Win32_Process queries"]
    D --> E["CIMWin32 WmiPrvSE<br/>53–61% CPU"]
    E --> F["WMI slows or cancels queries"]
    F --> G["Cleanup helpers overlap and accumulate"]
    G --> C

Once WMI/process enumeration slows, cleanup helpers overlap and later cleanup requests add more load, creating a positive feedback loop.

Full-restart control

After fully exiting and restarting Codex, I ran a 30-second non-WMI baseline:

| Measurement | Incident | After full restart |
|---|---:|---:|
| taskkill.exe creation | 410 / 20 sec | 0 / 30 sec |
| WmiPrvSE maximum CPU | 53.05% ETW / 61.1% UI | 0% across all four instances |
| Other loaded local Codex tasks | 2 active | Not loaded |

A restart clears the accumulated state, but it does not fix the underlying Windows cleanup path.

What steps can reproduce the bug?

1. Fully start Codex Desktop on Windows with a local folder available.
2. Run multiple local-agent tasks or subagents that issue shell commands, including commands that complete, time out, or are cancelled.
3. Keep the Desktop app open and continue local work.
4. Observe taskkill.exe, conhost.exe, and WmiPrvSE.exe in Task Manager or Process Explorer.
5. When the failure starts, taskkill.exe /pid <pid> /t /f instances are created continuously and CIMWin32 CPU rises sharply.
6. Fully exit and restart Codex. The storm returns to a zero-taskkill baseline.

The initiating trigger is intermittent. Once the first cleanup helpers overlap, the unbounded accumulation is readily observable. In this reproduction, two other local tasks were active and one was running several subagents plus Git/build/search operations. That is a plausible load amplifier, not a proven unique trigger.

Session identifiers are intentionally omitted because they refer to private local conversations; they can be provided through a private support channel if needed.

What is the expected behavior?

Windows process-tree cleanup should be bounded and should not require hundreds of concurrent taskkill.exe helpers or repeated full WMI process enumeration.

• Each execution should be cleaned up at most once.
• Cancellation and timeout handling should complete within a bounded time.
• Cleanup failure should activate backoff/circuit breaking instead of spawning more helpers.
• Child and descendant processes should still be terminated without being orphaned.
• Normal concurrent tasks/subagents should not materially increase WMI Provider Host CPU.

Additional information

Packaged-app implementation

Inspection of the installed app.asar found one taskkill.exe call site in the generic local execution-host cleanup path. On Windows it invokes approximately:

execFile(taskkill.exe, ["/pid", pid, "/t", "/f"], { windowsHide: true })

The Codex Micro/HID discovery module is separate from this call site.

Suggested fix and acceptance criteria

1. Prefer Windows Job Objects with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE or another non-WMI process-tree lifetime mechanism.
2. Add a process-wide cleanup concurrency bound or single-flight queue.
3. Add timeout, exponential backoff, and a circuit breaker around any fallback helper.
4. Log target PID, cleanup reason, duration, exit status, and concurrent cleanup count.
5. Under concurrent tasks/subagents, verify:

• zero taskkill.exe-originated Win32_Process queries,
• no orphan descendants,
• no repeated cleanup for the same execution,
• correct normal-completion, cancellation, timeout, and app-exit behavior.

A sanitized ETW export has been preserved and can be supplied through a private support channel. Raw logs are not attached publicly because they can contain local identifiers.