[Windows][26.715.3651.0] Cold launch spawns 300+ taskkill.exe/conhost.exe and freezes the whole PC

Open 💬 8 comments Opened Jul 18, 2026 by RainyMarks

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

Summary

On Windows, launching the new unified ChatGPT/Codex desktop app causes severe system-wide lag. Fully closing the app immediately restores normal system responsiveness.

This is reproducible from a cold app launch without invoking Computer Use or starting a new local tool call. About 15 seconds after the desktop main process starts, it begins spawning an apparently unbounded number of taskkill.exe processes and paired conhost.exe processes.

This report differs from #33776 and #33778 because the storm starts immediately after app startup, rather than only after roughly an hour of use or during an active local tool invocation.

Environment

Windows NT 10.0.26200.0, x64
64 GB system RAM
Desktop package: OpenAI.CodexBeta_26.715.3651.0_x64__2p2nqsd0c76g0
PowerShell configured as the integrated shell
WSL execution disabled in the desktop settings

Steps to reproduce

Fully exit the ChatGPT/Codex desktop app.
Launch it again into an existing local project.
Do not invoke Computer Use and do not intentionally start a new shell command.
Wait about 15 seconds.
Inspect the process list.
Observe rapidly accumulating taskkill.exe and conhost.exe processes.
Fully close the desktop app.
Observe that the system immediately becomes responsive again.

A complete app restart reproduced the problem with a new main-process PID.

Process evidence

One snapshot shortly after launch showed:

| Process | Count | Aggregate working set | Aggregate CPU time |
| --- | ---: | ---: | ---: |
| ChatGPT (Beta) | 8 | 1,028 MB | 131.4 s |
| taskkill.exe | 306 | 4,486.2 MB | 32.7 s |
| conhost.exe | 320 | 2,560 MB | 4.7 s |
| git.exe | 3 | 21.7 MB | 0 s |
| codex.exe | 1 | 236 MB | 11.9 s |

A subsequent sample showed 339 live taskkill.exe processes.

The app main process started first; the oldest live taskkill.exe appeared about 15 seconds later, and new instances continued to appear.

The Windows \Process(taskkill*)\Creating Process ID performance counter showed that almost every live taskkill.exe instance was created by the ChatGPT desktop main process.

In another sample, 65 live taskkill.exe processes were force-stopped. Within two seconds, 46 had already reappeared.

Git activity was separately reduced to zero during an earlier observation window, but the taskkill.exe / conhost.exe storm still reproduced, so Git polling does not explain this failure.

Relevant desktop logs

The current-session logs repeatedly contain:

warning [electron-sampler] Failed to collect child process snapshot

The failing command is:

Get-CimInstance Win32_Process |
  Select-Object ProcessId,ParentProcessId |
  ConvertTo-Json -Depth 2

Once the process storm is underway, the WMI call sometimes fails with:

HRESULT 0x80041006
Get-CimInstance: Not enough memory

The same startup also repeatedly logs bundled-plugin marketplace update failures:

[BundledPluginsMarketplace] plugin_marketplace_folder_write_failed
folderWritePhase=stop_chrome_native_host
[BundledPluginsMarketplace] bundled_plugins_marketplace_resolve_failed

A read-only file-count comparison found:

Bundled marketplace source in the installed package: 838 files
Generated user cache: 832 files

The desktop app then repeatedly retried the marketplace write/host-stop path while WMI child-process snapshots were failing. This may be a second trigger or an amplifier of the cleanup storm.

Mitigations attempted

Closed unrelated high-memory applications.
Fully restarted the desktop app.
Disabled the Computer Use plugin.
Removed the Computer Use turn-completion notification hook.
Disabled the Chrome plugin and Node REPL browser bridge.
Rebuilt the incomplete bundled-plugin cache from the installed package.
Enabled Git's local untracked cache and excluded only a local archive directory from status scanning.
Lowered the current desktop process priority.

A full app restart alone did not help. Closing the desktop app remains the only immediate way to restore normal system responsiveness. The longer-term result of rebuilding the bundled-plugin cache is still being evaluated.

Expected behavior

Launching the desktop app should not degrade the responsiveness of the entire Windows system.
Cleanup helpers must be reaped and their number must remain bounded.
A failed WMI process snapshot should fail cheaply, back off, and not trigger repeated process-tree cleanup.
Bundled-plugin cache updates should be atomic and should not enter a retry loop when the native-host stop/snapshot path fails.
It would be useful to have a supported switch to disable the Electron child-process sampler on Windows while this path is being fixed.

Related issues

#33776
#33778
#22912
#29499
#17229

Privacy note

This report intentionally omits the Windows username, local repository names, full local paths, conversation IDs, prompt contents, and raw log files. Sanitized logs or additional counter snapshots can be provided if maintainers request them.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 1 month ago

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

#34001
#33778
#33776

Powered by Codex Action

athan614 · 1 month 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.

thevone · 1 month ago

I can confirm the same failure mode on a newer non-Beta desktop package.

Environment

Windows x64
Desktop package: OpenAI.Codex_26.715.7063.0_x64__2p2nqsd0c76g0
20 logical processors
31.8 GB RAM
PowerShell/local tool execution

Observed behavior

During a local Codex session involving shell/process inspection, the desktop main process (ChatGPT.exe) entered the same cleanup storm and spawned hundreds of taskkill.exe processes, each with a paired conhost.exe.

A native parent-process snapshot showed:

529 descendants under the Codex desktop process tree
approximately 7,222 MB aggregate working set
approximately 3,442 MB aggregate private memory
the accumulating taskkill.exe processes were direct children of the desktop main ChatGPT.exe process

The normal Codex baseline before/after the storm was approximately 1.4–1.5 GB working set across 10–12 app processes.

WMI evidence

While the storm was active:

WmiPrvSE.exe reached approximately 538 MB working set, 325 threads, and 1,437 handles
the Winmgmt service host reached approximately 960 threads and 8,681 handles
together, WmiPrvSE and Winmgmt consumed roughly 30% of total CPU on this 20-logical-processor system
Get-CimInstance Win32_Process failed with HRESULT 0x80041006 / not enough memory
the WMI Activity operational log produced repeated event 5858 failures for Win32_Process queries

There were no event 5858 WMI failures in the preceding six-hour window before this reproduction.

Fully closing Codex stopped the new cleanup processes, matching the behavior reported here.

Recovery without reboot

A targeted recovery was successful:

Stop remaining taskkill.exe processes.
Stop the abnormal WmiPrvSE.exe provider hosts.
Restart the Winmgmt service and restore its previously running dependent services.

After recovery:

taskkill.exe: 0 at start and after a six-second observation
all WMI provider processes: approximately 79 MB combined working set
Codex total CPU: approximately 0.6%
Codex returned to its normal approximately 1.5 GB working-set baseline

This confirms the defect is still present in 26.715.7063.0, newer than the build in the original report. The failure path is consistent with unbounded desktop cleanup helpers plus WMI process-enumeration failure. A timeout, global concurrency bound, and backoff/circuit breaker around the Windows process-tree cleanup path appear necessary.

Privacy note: local usernames, repository paths, prompt contents, and raw session logs are intentionally omitted.

IkariKr · 1 month ago

I can reproduce this issue on another Windows machine, with the same failure signature.

Environment / reproduction

Windows x64
Codex Desktop / ChatGPT Windows app
The issue reproduces immediately after launching Codex Desktop, even when the app is otherwise idle.
WMI Provider Host (WmiPrvSE.exe) stays around 36–40% CPU (and can spike much higher).
Fully exiting Codex Desktop drops WMI CPU to approximately 2%.
Launching Codex Desktop again brings WMI CPU back to approximately 40%.
The VS Code Codex extension does not reproduce the problem on the same machine.

Direct evidence

Process Monitor showed ChatGPT.exe repeatedly creating:

taskkill.exe
conhost.exe
git.exe

WMI Activity tracing recorded approximately 615 WMI operations in about 15 seconds, involving more than 300 short-lived client PIDs. The repeated query was:

root\\cimv2: SELECT __PATH, ProcessId, CSName, Caption, SessionId, ThreadCount, WorkingSetSize, KernelModeTime, UserModeTime, ParentProcessId FROM Win32_Process

The high-CPU WMI host was confirmed to be running the built-in CIMWin32 provider from cimwin32.dll. The hot WMI host reached roughly 300% aggregate CPU in a multi-core sample.

This strongly indicates that the Desktop process sampler / cleanup loop is repeatedly spawning short-lived helpers and performing overlapping full process enumerations. Restarting or killing WMI only provides temporary relief; closing Codex is the reliable way to stop the load.

Please prioritize a fix for the Windows Desktop process sampler and cleanup path. In particular, a single-flight/concurrency limit, timeout with backoff/circuit breaker, and a supported way to disable Windows process sampling would prevent this from making the whole system unresponsive. This is a severe usability issue, and I hope it can be fixed as soon as possible.

ScotKinney · 1 month ago

Confirmed still reproducible on a newer production build today (2026-07-21).

Environment

Windows x64
Desktop package: OpenAI.Codex_26.715.8383.0_x64__2p2nqsd0c76g0
Main desktop executable: ChatGPT.exe
Computer Use was not initialized for this reproduction

Live evidence

A 4-second sample at 200 ms intervals observed:

94 unique taskkill.exe processes
22 peak concurrent taskkill.exe processes
total system CPU around 67–73%
the hottest WmiPrvSE instance around 1,205–1,275% Process CPU (roughly 12 logical cores)

The Windows performance counter \Process(taskkill*)\Creating Process ID identified desktop-main PID 72900 as the creator. That PID resolved directly to the production-package ChatGPT.exe main process.

A normal single Get-CimInstance Win32_Process snapshot briefly returned zero taskkill.exe instances while the rapid Get-Process sample caught 94 unique instances. This demonstrates how short-lived/recreated the helpers are and why WMI-based snapshots can underreport the storm while WMI itself remains saturated.

The process creation and WMI load match the original report and confirm that the regression persists in 26.715.8383.0, newer than both the original 26.715.3651.0 report and the 26.715.7063.0 confirmation above.

Please prioritize and assign this. The desktop cleanup/process-sampling path needs a single-flight global bound, child timeout/reaping, exponential backoff or a circuit breaker after WMI failure, and ideally an emergency setting to disable Windows process sampling. The affected Electron desktop implementation does not appear to be present in the public Codex repository, so downstream users cannot submit the actual fix here.

suiyuebaobao · 1 month ago

The cold-launch taskkill.exe/conhost.exe storm here is very close to the downstream behavior I measured; repeated Git refreshes were upstream in my reproduction.

I published a single-file Windows launcher for the original Microsoft Store/MSIX Codex app:

Repository: https://github.com/suiyuebaobao/codex-git-refresh-workaround
Direct download: https://raw.githubusercontent.com/suiyuebaobao/codex-git-refresh-workaround/main/Codex-Git-Disabled.cmd

It starts Codex with a process-scoped GIT_DIR=NUL. On my machine, the stable trace changed from 247 new git.exe and 137 new taskkill.exe processes per 10 seconds to 0 and 0 over 15 seconds; WMI Provider Host fell from about 6.6% to 0.9%.

Usage: fully exit Codex from the Windows system tray, then run the script.

This is an unofficial workaround, not an upstream fix. It deliberately disables or limits Review, Changes, branch detection, commit, and other Git-backed Codex features. It does not patch Codex, modify repositories or Git configuration, write system environment variables, require elevation, terminate processes, or remove chat history. Launching Codex normally restores Git integration.

5968qqq · 1 month ago

I can reproduce this on my Windows machine as well, and my reproduction is a clean idle-startup case.

Reproduction sequence:

Before launching Codex, Task Manager filtered for taskkill showed no results.
I launched Codex Windows desktop into a blank New project page.
I did not enter any prompt and did not run any terminal/tool command.
Around 19 seconds after launch, taskkill.exe and Terminal process entries began repeatedly appearing.
Around 40-50 seconds after launch, this became a visible process storm, with total system CPU around 50%-80%.
Fully exiting Codex from the system tray immediately stopped the repeated process creation, and Task Manager again showed no taskkill results.

Environment:

Codex package: OpenAI.Codex_26.715.7063.0_x64
Windows: Windows 11 25H2, build 26200.8875
RAM: 23.78 GB
Pagefile: fixed size, observed high usage during the incident
Workspace: blank New project / no user task submitted

I have a screen recording of the full sequence. The Help Center chat did not accept MP4/zip upload, but I can provide screenshots or the original recording if maintainers specify a preferred upload method.

I also took a quick look at the public source and this seems consistent with the Windows cleanup path needing stronger bounds around taskkill /PID <pid> /T /F: timeout, process-wide concurrency limit, per-target PID deduplication, backoff/circuit breaker after repeated cleanup failures, and ideally Job Object based cleanup for child processes Codex owns.

marijn-g · 1 month ago

I initially opened #35314 before GitHub suggested this issue. After comparing the logs, this appears to be the same cold-start failure path, so I am closing #35314 as a duplicate and adding current native ARM64 evidence here.

Reproduced on:

ChatGPT/Codex About version 26.721.41059 (released 24 Jul 2026)
AppX package 26.721.4979.0, native ARM64
Windows 11 Home Insider Preview build 26300, ARM64, 63.5 GB RAM
ChatGPT Business

On the first Codex launch after a full PC shutdown, and again after an app update/restart, the whole desktop stalls in several bursts. This has improved from 10+ second stalls to repeated 2–3 second stalls, but is not fixed.

Current log timings:

Main window ready: 1.947 s
Routes mounted: 2.934 s
Bundled plugin/marketplace reconciliation: 13.249 s
mcpServerStatus/list: 9.390 s
app/list: 14.542 s
Focus-triggered reconciliation: 5.607 s

The same startup window logs:

[electron-sampler] Failed to collect child process snapshot
failing Get-CimInstance Win32_Process ...
plugin_marketplace_folder_write_failed
bundled_plugins_marketplace_resolve_failed

I did not capture the taskkill.exe/conhost.exe process count during the stalls, but the matching trigger and log sequence strongly suggest this is the same parent issue. There is no AppHang/crash in my current session; responsiveness returns after startup initialization settles.

Personal paths, repository names, conversation IDs, and raw logs are omitted.