Windows Desktop: unbounded taskkill.exe/conhost.exe cleanup storm exhausts WMI

Open 💬 9 comments Opened Jul 20, 2026 by RocStone

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

Summary

Codex Desktop on Windows can enter an unbounded process-cleanup loop where hundreds of taskkill.exe processes remain alive, each with a corresponding conhost.exe. The accumulated taskkill instances repeatedly query Win32_Process, exhaust the WMI provider quota, and make the entire Windows UI sluggish or unable to launch new processes.

This is related to #17229 and #21957, but the leaking processes in this case are taskkill.exe themselves rather than only git.exe/conhost.exe or leaked stdout.

Environment

Codex Desktop: 26.715.4045.0
OS: Windows 25H2 x64, build 26200.8875
RAM: 32 GB
Installation: Microsoft Store/MSIX package OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0

Observed behavior

During normal local-agent use involving shell commands, cancellations, and command timeouts, process counts grew continuously.

Peak measurements:

taskkill.exe: 457 processes
conhost.exe: 473 processes
total processes: 1,388
total threads: over 14,000
total handles: over 350,000
WMI provider private memory: 720.5 MB

All sampled taskkill.exe instances had the Codex Desktop main process (ChatGPT.exe inside the OpenAI.Codex package) as their parent. Most excess conhost.exe instances were children of those taskkill.exe processes.

Windows Event Viewer recorded:

WMI event 5612: PrivatePageCount exceeded its 512 MB quota.
WMI event 5612: ThreadCount exceeded its 256-thread quota.
WMI Activity event 5858: repeated Win32_Process queries failed with 0x80041006 and 0x80041033.
taskkill.exe crashed with exception 0xc0000005 (Application Error event 1000 / Windows Error Reporting event 1001).

Killing the accumulated taskkill.exe processes immediately reduced the total process count from 1,388 to about 565, and WMI private memory fell from 720.5 MB to about 104 MB. However, while the original Codex process remained running, taskkill.exe counts grew again from 156 to 320 in 20 seconds.

Fully restarting/reinstalling Codex cleared the bad state. With the same app version reinstalled, the stable baseline was:

taskkill.exe: 0
conhost.exe: 12
total processes: about 390
WMI: 139 MB private memory / 54 threads

Because the reinstalled version is identical, this appears to clear the accumulated state rather than fix the underlying bug.

Relevant packaged-app implementation

Inspection of the installed app.asar shows that the Windows process-tree cleanup path invokes approximately:

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

The call does not appear to set a timeout. Cleanup is deduplicated per execution object, but there is no apparent global concurrency limit, backoff, or circuit breaker across multiple local executions. If taskkill.exe hangs because process enumeration/WMI is unhealthy, later cleanups can start additional taskkill.exe instances indefinitely.

Steps that may reproduce

Open Codex Desktop on Windows and a local repository.
Run multiple local shell operations, including operations that time out or are cancelled.
Observe taskkill.exe and conhost.exe in Task Manager or Process Explorer.
If WMI/process enumeration becomes slow, observe whether taskkill.exe instances remain alive and increase continuously.
Keep the app open and observe WMI event 5858 failures and growing process/thread/handle counts.

The trigger is intermittent; the unbounded accumulation after the first stuck cleanup is the main defect.

Expected behavior

A process-tree cleanup should complete or time out within a bounded period.
Codex should not run hundreds of concurrent taskkill.exe cleanup processes.
Repeated cleanup failures should activate backoff/circuit breaking and surface one actionable error to the user.
Failure of WMI/process enumeration should not cause a system-wide process storm.

Suggested fixes

Add a timeout to the taskkill.exe invocation and forcibly terminate a stuck cleanup helper.
Add a process-wide single-flight or small concurrency limit for Windows tree cleanup.
Add exponential backoff/circuit breaking after repeated cleanup failures.
Prefer Windows Job Objects or direct Win32 process-tree termination instead of spawning taskkill.exe for every cleanup.
Log the target PID, duration, exit status, and number of concurrent cleanup operations.

View original on GitHub ↗

9 Comments

github-actions[bot] contributor · 1 day ago

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

#33776
#33778
#34001
#34025

Powered by Codex Action

frank9306 · 23 hours ago

I'm also affected by this issue and would appreciate any updates on the progress. Thanks for the work on this.

msg7086 · 22 hours ago

26.715.4045.0 here also affected by this. My work laptop is frozen with 80% of the CPU wasted on ChatGPT taskkills.

askxue · 19 hours ago

I have been suffering from this bug for several days now. I hope it can be fixed as soon as possible.

adfras · 16 hours ago

I can reproduce this on a newer Codex Desktop build, so the issue persists beyond 26.715.4045.0.

Environment

Codex Desktop: 26.715.7063.0
Package: OpenAI.Codex_26.715.7063.0_x64__2p2nqsd0c76g0
Windows 11 Pro x64, build 10.0.26200
32 GiB RAM

Reproduction and evidence

After fully quitting Codex, restarting Windows, checking for app updates, and relaunching Codex, the process storm returned.

Many live C:\Windows\System32\taskkill.exe /pid <pid> /t /f processes accumulated.
Every sampled taskkill.exe had the packaged Codex desktop main process (ChatGPT.exe) as its direct parent.
Task Manager showed approximately:
Service Host: Windows Management Instrumentation: 14.5% CPU
WMI Provider Host: 13.1% CPU
ChatGPT/Codex: 8.2% CPU
Total system CPU: 67%
Even a trivial one-line PowerShell command invoked through Codex timed out.
A direct git status --short --untracked-files=no completed in about 0.2 seconds, so repository Git responsiveness was not the trigger in this reproduction.

The Codex desktop log repeatedly reports:

[electron-sampler] Failed to collect child process snapshot
powershell.exe ... Get-CimInstance Win32_Process ...

Windows WMI Activity event 5858 records repeated Win32_Process query failures from the cleanup processes with result codes:

0x80041032
0x800706BE
0x800706BA

Inspection of this build's packaged app.asar also shows that the Electron sampler:

constructs the Windows child-process snapshot worker unconditionally,
requests a heartbeat snapshot every 30 seconds while the primary window is focused,
permits additional triggered snapshots with a 5-second minimum interval.

This appears to amplify the failure: a timed-out WMI snapshot leads to taskkill cleanup; each stuck taskkill performs another Win32_Process query; later sampler cycles add more cleanup processes without effective global backoff/circuit breaking.

The same sampler failure first appears in local Codex logs from 2026-07-15 under desktop build 26.707.9981.0, and continues under 26.715.7063.0. No private paths, repository names, prompts, or raw logs are included here. Sanitized screenshots and selected log/event excerpts are available if maintainers need them.

lev-goryachev · 11 hours ago

+1. Made whole app completly unuseable. With 2 220$ subscriptions. Great work, devs!
win 10, 26.715.52143

NocturnalSk · 10 hours ago

Confirmed on a newer Microsoft Store build with another Windows 10 reproduction.

Environment

Codex Desktop package: OpenAI.Codex_26.715.7063.0_x64__2p2nqsd0c76g0
Package status/signature: Ok / Store
Bundled ChatGPT.exe file version: 150.0.7871.124
OS: Windows 10 Pro 22H2 x64, build 19045.6466
Logical processors: 16
Observed: 2026-07-21 00:24:08 (Asia/Shanghai)

Observed behavior and evidence

Task Manager showed the following simultaneous CPU spike:

Service Host: Windows Management Instrumentation: 14.1%
WMI Provider Host: 11.8%

A read-only process/event investigation found:

Winmgmt was hosted normally by C:\Windows\System32\svchost.exe -k netsvcs -p.
Windows svchost.exe, WmiPrvSE.exe, and taskkill.exe binaries had valid Microsoft signatures.
Before the screenshot, the WMI Activity log already contained 742 Event ID 5858 failures from 00:17 through 00:23. The operations repeatedly enumerated Win32_Process and Win32_PerfFormattedData_PerfProc_Process, with result codes including 0x800706BA, 0x80041032, and 0x80041033.
One live snapshot found 46 taskkill.exe processes, all direct children of the Codex Desktop main ChatGPT.exe process. Sampled command lines were of the form:

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

A later five-second sample started with 212 live taskkill.exe processes and ended with 202 still alive.
During one 15-second polling window, 1,092 distinct PIDs were observed (including the initial live set), showing extreme intermittent process churn.
A later five-second CPU sample showed Winmgmt and all four WmiPrvSE.exe instances back at 0%, consistent with a bursty query/cleanup storm rather than sustained load.
The WMI permanent-subscription check found no CommandLineEventConsumer or ActiveScriptEventConsumer; only the standard SCM event-log subscription was present. No TCP connections were owned by the WMI provider PIDs.

Two later diagnostic commands timed out and may have amplified the subsequent taskkill.exe count. However, the 742 WMI failures and the Task Manager spike occurred before those diagnostics, so the underlying cleanup/query storm was already active.

This matches the unbounded Windows cleanup behavior described in this issue and confirms that it still reproduces in Store build 26.715.7063.0 on Windows 10. A bounded timeout plus global concurrency limit/backoff around taskkill.exe would prevent this failure from escalating into system-wide WMI and process exhaustion.

Usernames, repository paths, conversation contents, and unrelated process details were intentionally omitted. A screenshot of the WMI CPU spike can be provided if useful.

noman-qadir · 9 hours ago

Additional WPR and controlled Git/MCP isolation evidence

I have an independent reproduction on:

Codex Desktop/MSIX 26.715.4045.0
Windows 11 25H2, build 26200.8875, x64
Native Windows Git repositories, not WSL

A 4.09 GiB Windows Performance Recorder trace captured the process storm with zero lost events or buffers. During its final 385-second incident window:

2,000 genuine taskkill.exe launches occurred.
1,986 were children of the main ChatGPT/Codex Desktop process.
1,908 targeted git.exe.
Approximately 1,983 Git launches ran git config --null --get core.fsmonitor.
Peak taskkill concurrency was 33, with a peak creation rate of 12 per second.

I later performed a controlled MCP-isolation comparison:

Temporarily disabled all five configurable local MCP servers and performed a clean restart, ending the residual ChatGPT processes that remained after normal close.
Codex still created app-managed Node/Node REPL helpers and rewrote config.toml, removing Node REPL’s disabled flag.
Four Codex-launched Git children remained alive: rev-parse HEAD, remote -v, config --null --get core.fsmonitor, and status --porcelain.
The identical direct git config --null --get core.fsmonitor command completed naturally in 91 ms.
A brand-new control task was instructed to return one line and use no tools. It added two persistent Node/Node REPL helper pairs.
That tool-free task left a Codex-launched git -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelain process alive.
The identical direct status command completed naturally in 98 ms with exit code 0.

Earlier logs also showed automatic title/description sessions initializing complete helper/MCP environments while recording zero MCP tool executions. During the full recurrence, ten matching local helper suites remained resident simultaneously.

Normal application closure was incomplete twice during the follow-up. Residual ChatGPT processes had to be ended through Task Manager; one idle residual group used approximately 755 MB.

This evidence supports a compound lifecycle problem:

Git commands launched through Codex can remain stuck even though identical direct commands complete immediately.
Visible and hidden sessions can retain eager MCP/helper environments after their work finishes.
The retained processes increase memory and process-table pressure.
Repeated cleanup through taskkill /T then enumerates that enlarged process table through WMI and can escalate into the reported storm.

After restoring the original MCP configuration and performing a final clean restart, the app was stable with one expected helper suite, zero Git, zero taskkill, and zero exact Win32_Process WMI failures during the final observation. This cleared the accumulated state but did not fix the underlying product defect.

I can provide the full WPR ETL, targeted WPA CSV exports, event-log details, process command lines, and timestamped chronology if useful.

Existing OpenAI feedback ID: 019f7bb3-69e7-7f23-8635-79b16e2eb930.

Related reports: #29408, #33531, and #34251.

Chronology note: #29408 documented the same Git polling command family on Codex versions 26.616.6631.0, 26.623.11225.0, and 26.707.62119. This indicates that the underlying Git polling defect predates 26.715; the WPR evidence above in this comment connects that older behavior to the downstream taskkill/WMI storm.

athan614 · 7 hours ago

Same issue here, ChatGPT/Codex windows app is stuck in a runaway process-enumeration loop with taskkill.exe whenever launched, causing WMI to get stuck at 25% CPU constantly, lagging my entire PC.