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

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

1. Fully exit the ChatGPT/Codex desktop app.
2. Launch it again into an existing local project.
3. Do not invoke Computer Use and do not intentionally start a new shell command.
4. Wait about 15 seconds.
5. Inspect the process list.
6. Observe rapidly accumulating taskkill.exe and conhost.exe processes.
7. Fully close the desktop app.
8. 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.