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

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

• #33776
• #33778
• #34001
• #34025

Powered by Codex Action

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

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

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

<img width="2539" height="1458" alt="Image" src="https://github.com/user-attachments/assets/ecbdb34c-4603-4454-bc21-3445d5698054" />

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.

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

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.

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:

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

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.

If I launch Codex Desktop directly in user mode, it spawns a large number of terminal processes and keeps failing repeatedly, with up to five or six hundred such processes running. Meanwhile, the WMI Provider Host process consumes over 50% of system resources. However, when I run it as administrator, no excessive terminal processes are created and WMI operates normally. This issue is most likely caused by a permission-checking process that keeps failing and restarting continuously.
Right Click Codex And Run As Administrator may be helpful.

Thanks.

Follow-up from my machine:

I tested the “run ChatGPT/Codex as administrator” suggestion.

Result: it did not clearly eliminate the issue here. It may have reduced the severity, but the behavior still appeared.

Test summary:

• Started a lightweight monitor using Get-Process only, sampling ChatGPT/codex/node/git/taskkill/WmiPrvSE.
• Closed ChatGPT normally.
• Waited, then ended remaining ChatGPT processes.
• Relaunched ChatGPT as administrator.
• Worked for roughly 10 minutes.
• Closed ChatGPT again.

Observed:

• Before the admin relaunch, the monitor captured a large spike, including 168 taskkill.exe processes in one sample.
• After the close/end period, there was a calm interval with no ChatGPT, codex, node, git, or taskkill processes.
• After relaunching ChatGPT as administrator, taskkill activity still reappeared, along with ChatGPT/codex/node/git activity.
• The machine felt usable during/after this run, so admin mode may have changed severity, but it did not look like a complete fix on this system.

Conclusion:
On my machine, admin launch may reduce severity, but it did not fully stop taskkill.exe activity. This suggests the underlying helper/process cleanup loop may still be active.

Additional reproduction on newer build; switching to Work mode was the trigger

This issue still reproduces on a newer Microsoft Store build.

Environment

• ChatGPT/Codex Desktop MSIX: 26.715.8383.0
• Package: OpenAI.Codex_26.715.8383.0_x64__2p2nqsd0c76g0
• Windows 10 Pro 22H2 x64, build 19045.6466
• 16 logical processors
• Observed: 2026-07-22 (Asia/Shanghai)

Trigger and user-visible impact

The incident started immediately after switching the newly updated unified desktop app to Work mode with a local folder available.

Task Manager then showed:

• ChatGPT (630): approximately 630 child processes
• ChatGPT/Codex group: 19.7% CPU and about 4,046.8 MB memory
• WMI Provider Host: 49.4% CPU and about 520.3 MB memory
• Total system CPU: 100%
• Hundreds of entries displayed as “Terminal Process”

The whole machine became severely degraded.

Process evidence collected before a full restart

A read-only process inventory found multiple retained helper suites:

• 12 node_repl.exe hosts
• 12 Firecrawl MCP server workers
• 12 Firecrawl npx launchers
• 24 Firecrawl-related cmd.exe wrappers
• 11 bundled mcp/server.mjs workers
• approximately 2.6 GB combined working set across the Codex-related helper population

The duplicated helpers were descendants of the packaged ChatGPT/Codex app-server process. Firecrawl was configured as npx -y firecrawl-mcp; it appears to amplify the process count, but the broader defect is that complete helper/MCP suites were repeatedly initialized and retained instead of being reused or reaped.

Windows Event Viewer recorded WMI event 5612 at 02:11:31:

• ThreadCount: 300
• warning threshold: 256
• provider: cimwin32.dll

Important diagnostic caveat: a subsequent read-only Get-CimInstance Win32_Process inventory likely amplified the WMI CPU spike visible in the screenshot. The 49.4% WMI number should therefore not be attributed entirely to the original Work-mode trigger. The core product symptom remains the approximately 630-process ChatGPT group and the repeated retained helper suites that existed before restart.

Recovery comparison

After fully quitting and reopening the desktop app:

• node_repl.exe: 1
• node.exe: 6
• codex.exe: 1
• WMI Provider Host CPU: 0%
• total system process count: 321

This cleared the accumulated state but does not fix the lifecycle defect.

This reproduction adds two data points to the existing report:

1. The issue persists in Store build 26.715.8383.0.
2. Switching into local Work mode can be a direct trigger for rapid helper/process fan-out.

The screenshot and additional sanitized process data are available if maintainers need them. Usernames, private paths, repository names, prompts, email addresses, and configuration secrets are intentionally omitted.

Follow-up: the trigger appears to be session-specific restoration

An additional user observation narrows the trigger further:

• The process storm appears when reopening the same Work conversation that was originally created/used in Work mode.
• Reopening that conversation appears to cause the problem to continue/recur.
• When that conversation is not reopened, a 10-second non-WMI baseline remained completely stable:
• total processes: 318 throughout
• taskkill.exe: 0
• conhost.exe: 7
• node_repl.exe: 1
• node.exe: 6
• WMI provider processes showed no active storm

This suggests the trigger may be restoration of persisted per-conversation tool/helper state, rather than merely launching the desktop app or installing the update. A stale Work conversation may rehydrate multiple MCP/helper environments or replay cleanup state each time it is opened.

This is currently a strong user observation, not a deliberately repeated controlled reproduction: we did not ask the user to reopen it again because the previous occurrence saturated the machine. The calm baseline was collected using Get-Process only, specifically to avoid amplifying WMI load.

Practical implication for diagnosis: compare a newly created Work conversation against reopening the affected persisted conversation, and inspect whether restored task/tool ownership records cause helper fan-out before any new tool call is made.

Independent reproduction with provider-level WMI trace and a restart control

I independently reproduced this failure and collected a short, sanitized provider-level trace.

Environment

• Codex Desktop MSIX: OpenAI.Codex_26.715.7063.0_x64
• Bundled ChatGPT.exe file version: 150.0.7871.124
• Windows x64
• 16 logical processors
• Microsoft Store installation

User-visible impact

During the incident, Task Manager showed approximately:

• Total system CPU: 80%
• WMI Provider Host: 17.5%
• Service Host: Windows Management Instrumentation: 7.8%

The machine was severely sluggish and ordinary commands launched through Codex were taking much longer than normal.

Provider and query evidence

A WMI provider health-counter sample identified CIMWin32 as the hot provider. Its raw processor counter ranged from approximately 241% to 393%, equivalent to about 15%–25% of the whole 16-logical-processor machine. Other active WMI providers were near zero.

A 12-second administrator WMI Trace capture recorded:

• 118 repeated CIMWin32 queries of Win32_Process, selecting process ID, parent PID, session, thread count, working set, and kernel/user CPU time.
• Provider events correlated those queries to cimwin32.dll inside the busy WmiPrvSE.exe host.
• In the same 12-second interval, process-start tracing recorded 107 git.exe launches and 106 taskkill.exe launches directly parented by the packaged desktop application's main ChatGPT.exe process.

This matches the cleanup/process-enumeration amplification described in this issue: Codex creates short-lived helpers, the helpers repeatedly enumerate Win32_Process, and the resulting WMI workload is charged to WmiPrvSE.exe / Winmgmt rather than primarily to the Codex process itself.

Before/after control

After fully quitting and restarting Codex, I repeated the same provider-counter check:

• Eight consecutive one-second samples showed 0.00% CPU for CIMWin32 and the other WMI providers.
• System responsiveness returned to normal.
• Some older Git helper processes remained, so restarting the app cleared the immediate WMI storm but should not be considered a permanent fix.

I did not establish a single repository-specific trigger in this reproduction. The captured evidence supports adding a bounded timeout, global concurrency limit, and backoff/circuit breaker around Windows process cleanup and process-snapshot helpers.

No raw trace is attached because it contains local identifiers. Sanitized aggregate results and selected redacted event records can be provided if useful.

The unbounded taskkill.exe/conhost.exe cleanup storm and WMI exhaustion here closely match 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.

Additional user observation after switching most local file/terminal work to FastCtx (an MCP tool runtime): for an initial period I did not see the previous taskkill.exe / conhost.exe accumulation or WMI-exhaustion behavior in ordinary Codex use.

Update: the storm has now recurred while writing this comment: 339 taskkill.exe and 351 conhost.exe processes, about 1,058 total processes, ~297,594 handles, and a WmiPrvSE instance at ~541 MB private memory. This is therefore not a fix and strongly supports the report's intermittent-trigger / unbounded-accumulation model.

FastCtx may have changed the workload and temporarily reduced the frequency of shell operations, cancellations, or timeouts that trigger cleanup, but it has not prevented the underlying Windows cleanup-path defect.

<!-- Retracted: submitted through an unintended connected GitHub account. -->

I can independently confirm this failure mode on the same Codex Desktop build, and I can add evidence for a likely trigger. This is not yet a deterministic minimal reproduction, so I am separating observed facts from the inferred mechanism.

Environment

• Codex Desktop: OpenAI.Codex_26.715.4045.0_x64 (Microsoft Store/MSIX)
• Windows: build 26200, x64
• RAM: approximately 48 GB
• Bundled Codex CLI observed in the session metadata: 0.144.5

User-visible impact

During the affected period, Windows Task Manager showed:

• Total CPU: approximately 77%
• WMI Provider Host: 14.2%
• Windows Management Instrumentation service host: 5.4%
• Microsoft Defender: 10.1%
• Desktop Window Manager: 7.1%
• ChatGPT/Codex process group: approximately 5%

The entire desktop visibly stuttered even though no heavy foreground application was running. CPU later returned to approximately 12% after the event subsided.

Likely high-probability trigger

A background Git review-summary operation was scanning a repository that contained 2,237 untracked and unignored files (approximately 26.5 MB) while another turn was actively generating and updating files.

The local Codex Desktop logs contained:

• 119 explicit review-summary abort records
• 63 aborts that directly referenced the untracked file tree
• aborts beginning about one second after the visible turn started
• residual abort activity continuing for approximately eight minutes after the visible work ended

A correlated ETW capture contained approximately 2,880 process-start records involving Git, conhost, and taskkill activity during the incident.

Inspection of the installed application bundle shows a stale Git snapshot path that advances the snapshot generation and calls AbortController.abort(). The Windows process-tree cleanup path then invokes approximately:

taskkill /pid <pid> /t /f

This makes stale review-summary cancellation a plausible trigger or amplifier for the unbounded cleanup/WMI storm. Source-level confirmation by a maintainer is still needed.

Suggested investigation areas

• Coalesce or debounce repeated review-summary refreshes while the worktree is changing.
• Enforce single-flight or bounded concurrency per worktree.
• Add timeout, backoff and a global concurrency limit around Windows taskkill cleanup.
• Avoid launching a new cleanup helper while an earlier cleanup for the same process tree is still pending.
• Prefer Windows Job Objects or a direct Win32 termination path.
• Log the Git operation, target PID, cancellation reason, cleanup duration and concurrent cleanup count.

Could a maintainer confirm whether stale review-summary cancellation reaches this Windows cleanup path and whether that path currently has a process-wide timeout or concurrency limit?

The project names, local paths, prompts and thread IDs have intentionally been omitted.

I published an independent, Windows-first diagnostic and containment skill for this failure signature while an upstream fix is pending:

https://github.com/onovich/fix-codex-lag.skill

FixCodexLag takes one bounded process snapshot, detects taskkill/conhost/Git-helper churn and correlated WMI/Defender pressure, and reports a clear confirmed / not detected / inconclusive verdict.

It asks before taking any action. A runtime tree is cleanup-eligible only when strong ownership and lifecycle evidence proves that its Codex task has ended. Active or ambiguous process trees are preserved.

This is a temporary community mitigation, not an upstream fix. If the storm is rooted in the shared app-server and no safe leaf can be isolated, the skill reports that rather than guessing. It does not address the separate logs_2.sqlite/WAL write-storm issue.

Confirmed on a newer Codex Desktop build with additional evidence connecting the cleanup storm, the Electron sampler, and review-summary cancellations.

Environment

• Codex Desktop: 26.715.10079.0
• Windows: 25H2 x64, build 26200.8875
• Microsoft Store/MSIX package
• Integrated terminal configured for PowerShell 7, but the internal sampler is unaffected because it explicitly invokes powershell.exe.

Live evidence

During the affected session, the process tree showed ChatGPT.exe -> taskkill.exe -> conhost.exe, with roughly 240 console-host processes present at the peak. WMI process enumeration then failed with resource/quota errors.

The packaged Desktop implementation contains two interacting paths:

1. The Electron performance sampler explicitly runs Windows PowerShell:

powershell.exe -NoProfile -NonInteractive -Command
Get-CimInstance Win32_Process ...
Get-CimInstance Win32_PerfFormattedData_PerfProc_Process ...

The packaged constants show:

• process snapshot timeout: 5 seconds
• app-state heartbeat: 30 seconds while the primary window is focused
• non-heartbeat trigger minimum interval: 5 seconds

The Desktop log recorded 14 [electron-sampler] Failed to collect child process snapshot events in this session, including repeated Win32_Process failures with HRESULT 0x80041006.

1. The Git worker recorded 120 completed background Git requests:

• 119 were requestKind=review-summary source=review_model
• 99 ended as abortedBeforeStart
• 20 ended as aborted after a process had started
• 1 timed out

For started Git work, the packaged local execution host uses killProcessTree=true; on Windows that calls:

taskkill.exe /pid <pid> /t /f

There is per-execution deduplication, but no visible process-wide concurrency limit, timeout, backoff, or circuit breaker around the taskkill.exe calls.

Healthy-state comparison

After the storm ended, without changing the Codex version:

• taskkill.exe: 0
• conhost.exe: 7
• WMI provider processes: 3, about 115 MiB total, 29 threads
• Win32_Process query: 390 ms
• Win32_PerfFormattedData_PerfProc_Process query: 651 ms

This supports a threshold/feedback-loop failure: on a healthy machine or healthy WMI state, the sampler finishes quickly and the helper exits; once cleanup processes accumulate and WMI exceeds the 5-second window or quota, sampler retries and additional cleanup work amplify the backlog. This also explains why another Windows PC with the same general workflow may not reproduce.

Requested fixes

• Add bounded timeout and global concurrency limiting to Windows taskkill.exe cleanup.
• Add exponential backoff/circuit breaking after sampler WMI failures.
• Avoid spawning Windows PowerShell for frequent resource sampling; prefer native process APIs.
• Coalesce or defer stale review-summary work so that a changing worktree does not repeatedly start and abort Git processes.
• Expose a temporary user setting to disable Desktop process sampling/background review refresh.

No prompts, usernames, repository names, or raw logs are included. Sanitized excerpts can be provided if needed.

Follow-up with a low-impact local mitigation result.

The affected saved-but-inactive repository had 350 untracked/unignored paths; 345 were generated artifacts under one top-level build directory. Git itself was healthy (status --untracked-files=all about 71 ms), so the issue was not a slow or corrupt Git repository. The Desktop review worker was nevertheless scheduling file-specific hash-object / diff work for those artifacts and aborting stale snapshots.

I added only a repository-local, non-committed exclusion:

# .git/info/exclude
/build/

No files were deleted, no tracked files changed, and no shared .gitignore was modified.

Result:

• untracked paths visible to Git: 350 -> 3
• first 20-second observation: 0 new Git completions, 0 new sampler failures, taskkill.exe=0
• second 35-second observation (covers the 30-second Desktop heartbeat): 0 new Git completions, 0 new sampler failures, taskkill.exe=0
• conhost.exe: 5, down from 7 at the recovered baseline
• WMI remained stable at about 115 MiB across 3 provider processes

This is not an upstream fix, but it is a substantially narrower workaround than launching with GIT_DIR=NUL: normal Git integration remains available, while generated artifacts are removed from background review snapshots. A per-project “disable background review/untracked scan” setting would still be valuable.

Independent reproduction on Codex Desktop for Windows, with a direct parent-chain capture.

Environment

• Codex Desktop MSIX: OpenAI.Codex_26.715.9757.0_x64__2p2nqsd0c76g0
• Native Windows workspace and PowerShell
• Multiple local Codex tasks were active, including large .NET build/test commands

Reproduction evidence

The initial affected snapshot contained:

• 195 live taskkill.exe
• 251 live conhost.exe
• approximately 6 GB combined working set
• severe system-wide UI lag

During a later observation window, the storm reproduced again:

• 98 new taskkill.exe processes were created in approximately nine seconds
• every sampled taskkill.exe had the same direct parent: the Codex Desktop root ChatGPT.exe (PID 2412 for that run)
• parent executable:

C:\Program Files\WindowsApps\OpenAI.Codex_26.715.9757.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe

• command lines were exactly:

C:\Windows\System32\taskkill.exe /pid <unique-pid> /t /f

• targets included transient PowerShell command helpers created by Codex Desktop

Large .NET operations amplified the resource impact: one solution build created 31 reusable MSBuild worker nodes in the same second. Another command returned Script running with cell ID ... and was not polled to completion before more work continued. These supplied many process trees for cleanup, but MSBuild did not launch taskkill.exe; the direct launcher was ChatGPT.exe.

Cleanup behavior

Stopping only the accumulated cleanup helpers temporarily recovered the machine:

• one pass stopped 145 taskkill.exe, leaving 0 immediately afterward
• conhost.exe fell to 57
• a graceful dotnet build-server shutdown reduced .NET processes from 33 to 1

However, while the same Codex Desktop host remained alive, the cleanup storm immediately returned:

• 183 taskkill.exe
• 209 conhost.exe
• after terminating another 175 killers, 93 were already present again by the end of the same command

This strongly supports an unbounded or re-entrant cleanup loop in the Desktop host. Killing individual helpers is not a stable workaround; fully exiting/restarting Codex Desktop is required to clear the active bad state.

Local mitigations applied

As defense in depth for the .NET amplification path, future Codex-launched builds are now serialized with a named mutex and forced to use:

• --disable-build-servers
• -m:1
• -nr:false
• -p:UseSharedCompilation=false
• MSBUILDDISABLENODEREUSE=1
• DOTNET_CLI_USE_MSBUILD_SERVER=0

These reduce child-process volume, but they cannot prevent the general Codex Desktop taskkill cleanup defect for non-.NET shell helpers.

Suggested product-level guard

Please consider a process-wide concurrency limit/single-flight guard, a hard timeout for each taskkill.exe, and circuit breaking after repeated cleanup failures. Using a Windows Job Object or direct Win32 termination would avoid spawning an external console process for every cleanup target.

This reproduction intentionally excludes usernames, private repository names/content, prompts, credentials, and application data.

@crmaris Thanks for the independent reproduction. Your direct parent-chain capture matches what we found on our affected Windows machine.

Our investigation narrowed the local amplification path as follows:

1. We confirmed that the accumulated taskkill.exe processes were launched directly by the packaged Codex Desktop ChatGPT.exe, not by PowerShell, Git, MSBuild, or the user.
2. Desktop logs showed repeated [electron-sampler] Failed to collect child process snapshot events while the sampler was querying Win32_Process through Windows PowerShell/WMI.
3. The Git worker was also repeatedly scheduling and aborting background review-summary work. Started executions used Windows process-tree cleanup, resulting in taskkill.exe /pid <pid> /t /f.
4. Git itself was healthy: a full untracked status completed in about 71 ms. The affected saved repository nevertheless exposed 350 untracked/unignored paths, 345 of which were generated files under one top-level build directory. Those artifacts caused additional file-specific hash-object/diff work and stale snapshot cancellation.

Our temporary containment was deliberately repository-local and non-committed:

# .git/info/exclude
/build/

No generated files were deleted, no tracked files changed, and the shared .gitignore was not modified. This reduced the untracked paths visible to the Desktop review worker from 350 to 3.

After first fully exiting/restarting Codex to clear the already-active bad state, we observed two clean windows:

• 20 seconds: 0 new Git completions, 0 new sampler failures, taskkill.exe=0
• 35 seconds, covering the 30-second Desktop heartbeat: 0 new Git completions, 0 new sampler failures, taskkill.exe=0

This has been an effective local workaround for that repository while preserving normal Git integration, but it is not an upstream fix. It only removes one strong amplification source; the general Desktop cleanup defect can still affect non-Git/non-.NET helpers. Once the storm is already active, killing individual helpers is ineffective, as you observed; a full Desktop restart is needed to reset the host state.

Independent reproduction on the same Windows desktop build confirms this issue, including the cold/idle startup variant.

Environment

• Codex Desktop package: OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0
• Bundled cleanup runner observed: codex-command-runner-0.145.0-alpha.18
• Windows 11 x64
• 32 GB RAM

Observed behavior

Merely launching Codex/ChatGPT Desktop, without intentionally starting a task, caused process, thread, handle, and memory counts to grow continuously. Fully closing the Codex/ChatGPT processes caused the counts to fall back toward baseline.

A live snapshot during the storm showed:

• Total processes: 1,669
• Total threads: 11,179
• Total handles: 398,810
• taskkill.exe: 618 processes / 114,606 aggregate handles
• conhost.exe: 649 processes / 63,534 aggregate handles

Earlier before/after screenshots from the same launch showed growth within approximately 101 seconds from:

• Processes: 313 -> 871
• Threads: 5,079 -> 8,701
• Handles: 147,879 -> 251,813
• Used RAM: 11.4 GB -> 17.6 GB

The counts continued increasing after that snapshot.

Parent-process confirmation

A WMI-independent Toolhelp32 process-tree capture was used because WMI became too slow to answer during the storm. In one diagnostic sample, all 587 live taskkill.exe instances had the Codex Desktop ChatGPT.exe process (PID 28712) as their direct parent:

Parent: 28712, ChatGPT
ChildCount: 587
ChildHandles: 110604

Closing Codex stopped the spawning and returned the system to approximately 380 processes / 5,000 threads / 150,000 handles.

This independently supports the existing diagnosis that the desktop cleanup path can enter an unbounded taskkill.exe spawn loop. It also confirms that the trigger can occur immediately after restoring/launching the desktop app, before the user intentionally initiates a new task.

A sanitized diagnostic ZIP containing six-sample process timelines, parent PIDs, grouped handle/thread/RAM counts, app versions, and no chat/config contents is available if maintainers need it.

26.715.72359 still exist. Codex dev folks, do you realize that it's a blocker not even major bug? The desktop app is complitly unuseable. Like at all =)
And we all still paying subscription for the unuseable app. Is there any workarounds maybe? till the official fix.

Independent reproduction: 26.715.10079.0, WmiPrvSE at 49% CPU, 39k CPU-seconds

Same failure mode on a newer Store build.

Environment

• Codex Desktop: OpenAI.Codex_26.715.10079.0_x64__2p2nqsd0c76g0
• Windows 11 25H2 x64, build 26200
• 32 GB RAM
• Native Git repos, no WSL

Live evidence from an active storm

WmiPrvSE.exe PID 101532 accumulated 39,325 CPU-seconds in ~2 hours -- sustained 49% CPU. Three WmiPrvSE instances were running.

Every live taskkill.exe was a direct child of ChatGPT.exe PID 85172 (Codex Desktop main process). All ran taskkill.exe /pid <pid> /t /f. 13 instances alive at capture, spawning at 3-5/sec.

Full process tree under PID 85172:

• 7 ChatGPT.exe (main + 6 renderer/GPU/utility/crashpad)
• 2 codex.exe (app-server + code-mode-host)
• 16 node_repl.exe (orphaned from closed tabs)
• 2 powershell.exe (Codex's Electron performance sampler running WMI queries)
• 13+ taskkill.exe + matching conhost.exe children
• 1 git.exe hung on hash-object in one repo

Sampler amplifies the loop

The two powershell.exe children are Codex's [electron-sampler]. Every 30 seconds it runs:

Get-CimInstance Win32_Process ...
Get-CimInstance Win32_PerfFormattedData_PerfProc_Process ...

This is Codex monitoring its own child processes via WMI. When the taskkill pile-up starts, these queries slow down, hit the same WMI quota, and log [electron-sampler] Failed to collect child process snapshot. Retries add more WMI load.

So the feedback loop has three participants:

1. Git ops hang -> Codex spawns taskkill /T
2. taskkill queries Win32_Process via WMI -> WMI load spikes
3. The Electron sampler independently queries Win32_Process every 30s -> adds to WMI load
4. WMI slows -> taskkill hangs -> more taskkill spawned -> sampler retries -> accelerates

If the sampler used CreateToolhelp32Snapshot instead of WMI on Windows, it would remove one amplifier.

Workaround tested
Stop-Process -Name ChatGPT,codex -Force killed the tree. WmiPrvSE CPU dropped from 49% to near zero in 30 seconds. Relaunch worked normally.

Per-repo .git/info/exclude additions reduced Git scanning volume, but the underlying taskkill/WMI loop is still present.

I was able to recover my working environment, by deleting all conversations and projects from codex app, i.e. performing a factory reset.

1. Go to ~/.codex/sessions and remove all sessions. You can backup to a different directory instead of deleting them.
2. Renaming or deleting ~/.codex/.codex-global-state.json file.

Then when you start codex app, you should get a clean and empty workspace, and the CPU usage should drop quickly.

If you have unfinished sessions, use codex CLI instead, resume your conversation, ask it to dump a handover markdown file. You can then pick the handover file in codex desktop app later, after the reset.

I published a standalone MIT-licensed containment guard for this specific Windows failure mode:

https://github.com/PPandYY/codex-windows-taskkill-guard
Release: https://github.com/PPandYY/codex-windows-taskkill-guard/releases/tag/v0.1.0

This is a temporary community mitigation, not an upstream fix.

The guard:

• uses NtQuerySystemInformation-based native snapshots rather than WMI;
• acts only after two consecutive samples see at least two taskkill.exe children directly owned by a package-verified Codex ChatGPT.exe;
• fails closed unless the package family, app\ChatGPT.exe suffix, System32\taskkill.exe path, PID/creation-time identity, and direct parentage all match;
• enters a latched zero-helper isolation state, lowers only the exact offending Codex parent to BelowNormal, runs the guard at AboveNormal, and releases after 10 quiet seconds;
• follows Store updates by validating package identity and the package-relative executable instead of pinning a build number.

On one affected Windows machine, under the same 30-second workload:

• taskkill.exe peak: 26 -> 5
• conhost.exe peak: 39 -> 17
• WMI whole-machine CPU share: ~14.4% -> ~1.83%
• guard CPU share: ~1.5%

The trade-off is explicit: suppressing cleanup helpers during a storm can leave an individual tool child running. The guard never terminates Codex or conhost.exe, and never broadens its target set.

The public repo includes 34 Python tests plus PowerShell installation/rollback fixtures. This result supports implementing a process-wide cleanup concurrency/timeout fix upstream and replacing the Desktop WMI sampler with native process APIs.

Current build still contains the disposal-to-taskkill path

I reproduced this again after updating to the current Microsoft Store package:

• Codex Desktop package: OpenAI.Codex_26.721.3996.0_x64__2p2nqsd0c76g0
• Windows x64
• Native Windows Git workspaces

With the normal profile, the storm still starts during cold launch. Removing all pinned tasks did not prevent it: one controlled run observed 40 unique taskkill.exe processes, about 3.8 GiB peak Desktop working set, and heavy disk activity within the first minute. Direct Git control commands against the same repositories completed normally in approximately 1.5–3.4 seconds.

Read-only inspection of this exact installed build's app.asar shows a more specific cleanup trigger than a generally slow Git repository:

1. The local execution host exposes child stdin as an RPC-backed WritableStream.
2. When the last RPC stub reference is disposed while the stream is not marked closed, WritableStreamStubHook.dispose() calls writer.abort(...).
3. The local execution host's stdin abort handler invokes child cleanup.
4. With killProcessTree=true, the Windows cleanup path invokes:

``text
taskkill.exe /pid <pid> /t /f
``

1. The taskkill execFile call still has no visible hard timeout, process-wide concurrency limit, per-target single-flight guard, backoff, or circuit breaker.

This means normal RPC stub disposal can be interpreted as cancellation and reach process-tree termination even when the read-only Git operation itself is not slow. Large/restored workspaces and long task histories increase the number of background Git/RPC lifecycles, but they are amplifiers rather than the root defect.

A separate clean isolated CODEX_HOME with no sessions, projects, or authentication produced no taskkill storm, but still reached roughly 2.5 GiB Desktop working set and heavy plugin-related disk I/O. That separates the general startup resource problem from this cleanup defect; deleting conversation history is not a complete fix.

Suggested product-side fixes:

• close child stdin explicitly on normal completion before disposing the RPC stub;
• do not treat disposal of an unused/unclosed proxy as cancellation of an already completed child;
• add a hard timeout, global concurrency limit, and per-target deduplication around Windows tree cleanup;
• replace or circuit-break the WMI-based process sampler after snapshot failures.

Acceptance should include completed read-only Git commands whose RPC stubs are disposed without launching taskkill.exe, plus a stress test proving cleanup concurrency remains bounded when many background Git operations are cancelled.

No usernames, repository names, absolute user paths, session contents, credentials, or raw traces are included. Sanitized ETW/log excerpts can be provided if a maintainer requests a specific format.

Independent reproduction on 26.715.10079.0

I independently reproduced this issue using read-only monitoring that did not stop, pause, or modify any running applications.

Evidence collected during the active slowdown:

• 245 new taskkill.exe processes in 8 seconds (~30.6 launches/second).
• Every observed taskkill.exe was a direct child of the packaged Codex Desktop ChatGPT.exe.
• A separate 10-second WMI trace recorded 576 ExecQuery starts (~57.6/second).
• The repeatedly executed query enumerated Win32_Process, including process IDs, parent IDs, working sets, thread counts, and CPU times.
• Native CPU sampling attributed approximately 3.32 CPU cores to WmiPrvSE.exe and 1.34 cores to the Winmgmt service host.
• Whole-system native sampling measured substantial CPU activity even while Task Manager’s aggregate display showed approximately 0%.

User-visible impact included browser updates occurring only every few seconds, delayed typing in text fields, delayed mouse-hover feedback, and general desktop sluggishness. Memory, disk, and GPU saturation were not observed.

The app was intentionally left running because active background work could not be interrupted, so a restart comparison was not performed. Raw ETL traces and process exports have been retained locally but are not attached publicly because they may contain local paths, identifiers, command lines, or unrelated process information. A sanitized extract can be provided through an appropriate private channel if requested.

Follow-up: process storm contained, but a separate full-rollout scan still makes Desktop unusable

I ran controlled local experiments against the current Store build 26.721.3996.0 using a disposable portable copy. The real sessions were never deleted or modified.

The reproduction includes an active legacy goal thread whose JSONL rollout is about 4 GiB. Removing pinned tasks did not help.

What the experiments separated

1. Patching the Electron cleanup path to stop spawning taskkill.exe, and disabling the WMI child-process sampler, prevented the original unbounded taskkill process storm. Process count stayed bounded.
2. Desktop was still unusable: after the UI resumed the large thread, total Desktop working set grew from roughly 600 MiB to 4.5 GiB and the bundled codex.exe sustained roughly 100-140 MiB/s reads until an external guard terminated only the disposable build.
3. Direct app-server tests showed that a patched cheap resume path itself can be bounded:

• legacy thread/read(includeTurns=true): about 60 KiB returned in under 1 second;
• thread/resume with excludeTurns=true, a 5-turn initial page, and deferred goal continuation: 61 KiB response, 6.4 seconds, about 279 MiB peak backend working set, and no automatic turn.

1. In the full Desktop flow, immediately after thread/resume, the renderer sends thread/goal/get and then thread/goal/set. That second request starts the destructive scan.

Specific backend path

In app-server/src/request_processors/thread_goal_processor.rs, both goal set and clear call reconcile_thread_goal_rollout(...). It unconditionally calls reconcile_rollout(...) with no builder and no incremental items.

In rollout/src/state_db.rs, that shape falls through to metadata::extract_metadata_from_rollout(...), which scans the rollout file. For an already materialized thread whose metadata row already exists in SQLite, this is redundant, but it rereads the complete multi-gigabyte legacy JSONL.

The app-server trace showed thread/goal/set entering codex_rollout::recorder / rollout reconciliation at exactly the point where backend disk reads and RAM growth began.

Suggested product-side change

Before reconciling a goal mutation, check whether the thread metadata row already exists in StateRuntime:

• existing metadata row: perform the goal mutation directly; SQLite is already available and the goal service reads/writes it;
• missing metadata row: use the current rollout reconciliation as the slow migration/read-repair path, then fail if the row still does not exist.

An acceptance test should use a large legacy rollout with existing SQLite metadata and verify that thread/resume followed by thread/goal/set reads only a bounded suffix / incremental data, does not materialize the full JSONL, and does not start a turn when goal continuation is deferred.

This appears to be a compound failure:

• the taskkill/WMI cleanup loop is one root defect;
• unconditional full-rollout reconciliation on goal mutation is another;
• a large legacy goal thread is a reliable trigger, not the underlying cause.

The local patches were diagnostic only and are not presented as a production-ready fix. I am stopping the experiments and cleaning up the disposable build, but this should provide a narrower upstream target without requiring users to delete their conversations.

Current-build follow-up: 26.721.4979.0 isolates two repeated WMI snapshot callers

I reproduced the remaining WMI polling on the current Windows Store package:

• Windows 10 Pro 22H2 x64, build 19045.6466
• Store package OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• The signed MSIX and app.asar were not modified

A 10.097-second Microsoft-Windows-Kernel-Process ETW baseline recorded 14 direct powershell.exe children of the Electron main process (1.387/s), with the active WmiPrvSE.exe processes consuming about 0.286 logical cores in aggregate.

Windows PowerShell Event 400/403 recorded only these two commands in that window:

Get-CimInstance Win32_Process |
  Select-Object ProcessId,ParentProcessId

Get-CimInstance Win32_PerfFormattedData_PerfProc_Process
Get-CimInstance Win32_Process -Filter "ProcessId = ..."

A short, reversible ChildProcess.spawn trace in the Electron main process identified the exact remaining stack:

listProcessSubtrees (IW)
  -> RW
     -> VW  # full Win32_Process parent/child snapshot
     -> WW  # PerfProc + filtered Win32_Process detail snapshot

Current bundle inspection shows two independent callers:

1. ElectronSampler.addChildProcessFields() creates the dedicated child-process-snapshot-worker.js worker.
2. The exported process-manager class (tX in this build) calls listProcessSubtrees from upsert/complete, retries at [0, 100, 300, 600] ms, and then falls back to a detached-process candidate scan.

To isolate causality without restarting Codex, I temporarily neutralized only those two seams in the same Electron PID:

• the exact worker name/file returned an empty telemetry snapshot;
• only the process manager's listProcessSubtrees and listDetachedProcessCandidates dependencies returned empty arrays.

The real execution host, ordinary worker construction, Git, PowerShell, and the taskkill.exe cleanup function were not globally intercepted.

Results:

| State | Window | Direct PowerShell children | Rate | Aggregate WmiPrvSE core equivalent |
| --- | ---: | ---: | ---: | ---: |
| Baseline | 10.097 s | 14 | 1.387/s | 0.286 |
| Both snapshot seams neutralized | 10.063 s | 0 | 0/s | 0.000 |
| Restore/reapply verification | 10.048 s | 0 across all 9 current ChatGPT PIDs | 0/s | 0.023 |

The last small provider-host delta was not accompanied by any child process start from any current ChatGPT PID. The Electron main PID and start time did not change, the temporary loopback Inspector was closed, and no ETW session remained.

This is a causal isolation, not a suitable product workaround: returning empty process snapshots can make background/detached-process attribution incomplete.

Suggested product fix:

• replace both PowerShell/CIM paths with one coalesced native Windows snapshot (NtQuerySystemInformation or Toolhelp32 plus process metrics);
• share/cache that snapshot between the Electron sampler and process manager instead of launching separate full-system queries;
• pass the execution host's known OS PID into the process manager so short commands do not trigger four full retries;
• single-flight and rate-limit fallback discovery, and stop retrying once the command has already completed without a usable PID;
• keep cleanup bounded independently so a failed snapshot cannot amplify into a taskkill.exe/WMI feedback loop.

The Electron Desktop implementation is not present in the public repository, so I cannot submit the product-code PR against openai/codex. This comment provides the current-build call sites and controlled A/B for the private Desktop implementation.

while we believe 26.730.7989.0 substantially improves the WMI storm, there are still many cases of taskkill floods that we need to resolve separately. leaving this issue open to track taskkill issues, but if you were suffering mostly WMI-related system exhaustion, re-test on 26.730.7989.0

I can confirm that I am still experiencing this issue on Windows 11 Pro, and my codex version is 26.803.10989.0. As soon as I launch the ChatGPT/Codex desktop application, it spawns a bunch of taskkill/git tasks and then my WMI Provider Host process spikes. If left alone it causes a system crash, but if I kill the ChatGPT/Codex desktop application in task manager the WMI storm subsides and everything goes back to before I tried to launch.

Windows 11 Pro, updated to ChatGPT/Codex desktop version 26.810.41047 and launched without seeing these issues anymore.