Repository navigation
[Windows][26.715.3651.0] Cold launch spawns 300+ taskkill.exe/conhost.exe and freezes the whole PC #34025
Description
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.exeandconhost.exeprocesses. - 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 2Once 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
- [Windows][Desktop 26.707.12708.0] ChatGPT.exe spawns hundreds of taskkill.exe/conhost.exe processes, causing WMI storms and DWM degradation #33776
- Windows Codex desktop app spawns hundreds of taskkill.exe and conhost.exe during local tool execution #33778
- Windows desktop freezes while electron-sampler fails WMI process snapshots in sandbox #22912
- Codex triggers high CPU usage in WMI Provider Host on Windows after startup #29499
- Codex Windows App keeps spawning
git.exe status --porcelain=v1 -zand leaves orphangit.exe/conhost.exeprocesses #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.
Activity
github-actions commentedon Jul 18, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
athan614 commentedon Jul 20, 2026
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 commentedon Jul 21, 2026
I can confirm the same failure mode on a newer non-Beta desktop package.
Environment
OpenAI.Codex_26.715.7063.0_x64__2p2nqsd0c76g0Observed behavior
During a local Codex session involving shell/process inspection, the desktop main process (
ChatGPT.exe) entered the same cleanup storm and spawned hundreds oftaskkill.exeprocesses, each with a pairedconhost.exe.A native parent-process snapshot showed:
taskkill.exeprocesses were direct children of the desktop mainChatGPT.exeprocessThe 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.exereached approximately 538 MB working set, 325 threads, and 1,437 handlesWinmgmtservice host reached approximately 960 threads and 8,681 handlesWmiPrvSEandWinmgmtconsumed roughly 30% of total CPU on this 20-logical-processor systemGet-CimInstance Win32_Processfailed withHRESULT 0x80041006/ not enough memoryWin32_ProcessqueriesThere 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:
taskkill.exeprocesses.WmiPrvSE.exeprovider hosts.Winmgmtservice and restore its previously running dependent services.After recovery:
taskkill.exe: 0 at start and after a six-second observationThis 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 commentedon Jul 21, 2026
I can reproduce this issue on another Windows machine, with the same failure signature.
Environment / reproduction
Direct evidence
Process Monitor showed ChatGPT.exe repeatedly creating:
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 commentedon Jul 21, 2026
Confirmed still reproducible on a newer production build today (2026-07-21).
Environment
OpenAI.Codex_26.715.8383.0_x64__2p2nqsd0c76g0ChatGPT.exeLive evidence
A 4-second sample at 200 ms intervals observed:
taskkill.exeprocessestaskkill.exeprocessesWmiPrvSEinstance around 1,205–1,275% Process CPU (roughly 12 logical cores)The Windows performance counter
\Process(taskkill*)\Creating Process IDidentified desktop-main PID72900as the creator. That PID resolved directly to the production-packageChatGPT.exemain process.A normal single
Get-CimInstance Win32_Processsnapshot briefly returned zerotaskkill.exeinstances while the rapidGet-Processsample 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 original26.715.3651.0report and the26.715.7063.0confirmation 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 commentedon Jul 22, 2026
The cold-launch
taskkill.exe/conhost.exestorm 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:
It starts Codex with a process-scoped
GIT_DIR=NUL. On my machine, the stable trace changed from 247 newgit.exeand 137 newtaskkill.exeprocesses 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 commentedon Jul 22, 2026
I can reproduce this on my Windows machine as well, and my reproduction is a clean idle-startup case.
Reproduction sequence:
taskkillshowed no results.taskkill.exeand Terminal process entries began repeatedly appearing.taskkillresults.Environment:
OpenAI.Codex_26.715.7063.0_x6426200.8875I 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 commentedon Jul 25, 2026
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:
26.721.41059(released 24 Jul 2026)26.721.4979.0, native ARM6426300, ARM64, 63.5 GB RAMOn 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:
mcpServerStatus/list: 9.390 sapp/list: 14.542 sThe same startup window logs:
[electron-sampler] Failed to collect child process snapshotGet-CimInstance Win32_Process ...plugin_marketplace_folder_write_failedbundled_plugins_marketplace_resolve_failedI did not capture the
taskkill.exe/conhost.exeprocess 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.