[Windows][Desktop 26.707.12708.0] ChatGPT.exe spawns hundreds of taskkill.exe/conhost.exe processes, causing WMI storms and DWM degradation

[Windows][Desktop 26.707.12708.0] `ChatGPT.exe` spawns hundreds of `taskkill.exe` and `conhost.exe` processes, causing WMI failure storms and DWM degradation

Summary

Codex Desktop on Windows repeatedly leaves taskkill.exe and conhost.exe processes running. During an affected session, 287 live taskkill.exe processes were direct children of the Codex Desktop main process (ChatGPT.exe), with 302 associated conhost.exe processes.

At the same time:

Windows Management Instrumentation recorded 987 failed queries in two hours.
The Desktop Window Manager handle count increased from 1,205 to 4,458 without a DWM restart.
Closing ordinary application windows left a white frame visible for about two seconds.
Windows UI responsiveness degraded, and DWM CPU usage remained elevated.

The problem returned within about one hour after a clean Windows restart.

Environment

Windows 10 Pro 22H2, build 19045.6466, x64
Codex Desktop MSIX package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
Bundled Chromium / ChatGPT.exe: 150.0.7871.115
GPU: NVIDIA GeForce RTX 2080 Ti
NVIDIA driver: 572.16
Display environment also included remote-display and virtual-display software. These may amplify DWM load, but the abnormal taskkill.exe parent chain points directly to ChatGPT.exe.

User-visible symptoms

DWM CPU usage rises and remains above its normal idle level.
Closing a window leaves a white rectangular frame for about two seconds.
Typing and application rendering become unreliable when the condition worsens.
Fully restarting Windows clears the condition temporarily.
The problem returns while Codex Desktop remains in use.

Process-tree evidence

At 2026-07-17 13:21 local time, a Toolhelp process-tree snapshot showed:

Process	Live count	Parent
`taskkill.exe`	287	All 287 were direct children of `ChatGPT.exe` PID 7516
`conhost.exe`	302	The newly created instances were children of the `taskkill.exe` processes
`ChatGPT.exe`	8	Main process PID 7516
`codex.exe`	1	Child of `ChatGPT.exe` PID 7516
`codex-code-mode-host.exe`	1	Child of `codex.exe`

The process storm was still active: conhost.exe increased from 296 to 302 in five seconds, while the total process count increased from 897 to 907.

DWM and Codex resource growth

DWM was not restarted during this comparison; it remained PID 2108.

Measurement	Healthy baseline after restart	Affected state about one hour later
DWM handles	1,205	4,458
DWM private working set	about 29 MiB	about 56 MiB
DWM processor-time counter	about 9-21%	about 42-85%
`codex.exe` handles	about 542 after a fresh launch	about 3,565

The processor-time values above use the Windows per-process performance-counter scale, not Task Manager's whole-system CPU percentage.

GPU counter samples during the affected state showed approximately 177 MiB of local GPU memory attributed to DWM and 100-116 MiB attributed to a ChatGPT.exe GPU process. No corresponding GPU-process crash, DXGI device-loss, or out-of-memory message was found in the Codex logs.

WMI failure storm

The Microsoft-Windows-WMI-Activity/Operational log contained 989 events over two hours. Of these, 987 were Event ID 5858 failures.

A representative failure contained:

Operation = Start IWbemServices::ExecQuery - root\cimv2 :
SELECT * FROM Win32_Process
WHERE ProcessId = ... OR ProcessId = ... [hundreds of process IDs]

ResultCode = 0x800706BA
PossibleCause = Could not send status to client

The recorded ClientProcessId belonged to a short-lived process that had already exited when inspected. The queries repeatedly enumerated a very large set of process IDs, including the accumulating console and cleanup processes.

This explains why the Windows Management Instrumentation service intermittently reached about 20% CPU even though a later 10-second sample returned to 0%: the load occurs in bursts during the failed query loop.

Codex renderer and Windows event evidence

The affected Codex session logged 88 instances of:

ResizeObserver loop completed with undelivered notifications.

They appeared in bursts while the primary renderer window was focused and visible.

No new NVIDIA display-reset event, DWM crash, DXGI device loss, or GPU out-of-memory event was recorded during the clean recurrence window.

Earlier affected sessions also produced Windows Error Reporting records for ChatGPT.exe, including MoAppHang, Top level window is idle, exception 0xc06d007f, and signature PCH_84. Those records may be related but are not required to reproduce the process and WMI growth described above.

Steps to reproduce

Restart Windows to clear all residual processes.
Open Codex Desktop and work in a local task that invokes shell commands.
Continue using the task for approximately one hour. Commands that time out, are cancelled, run concurrently, or produce large output may increase the reproduction rate, but the exact trigger has not been isolated.
Inspect the process tree under the main ChatGPT.exe process.
Observe accumulating taskkill.exe processes and their conhost.exe children.
Inspect Microsoft-Windows-WMI-Activity/Operational for repeated Event ID 5858 failures containing large Win32_Process queries.
Observe DWM handle growth and close an ordinary application window. The closed window may leave a white frame for about two seconds.

Expected behavior

Codex should terminate or reap its Windows cleanup subprocesses.
Process-tree cleanup should not leave hundreds of taskkill.exe or conhost.exe instances.
Cleanup should not repeatedly query hundreds of stale process IDs through WMI.
DWM resource usage and general Windows UI responsiveness should remain stable during long Codex sessions.

Working diagnosis

The evidence is consistent with a Windows process-cleanup or cancellation loop in Codex Desktop. The main ChatGPT.exe process repeatedly starts taskkill.exe, while WMI is used to inspect a growing process tree. Short-lived query clients exit before WMI can return status, producing repeated Event ID 5858 failures. The accumulated console processes and handles then increase DWM and system UI load.

This is an inference from the live parent chain, counters, and event timing. Source-level confirmation would require inspection by the Codex maintainers.

Current workaround

Fully exit Codex Desktop instead of only closing its window.
Restart Windows if residual taskkill.exe or conhost.exe processes remain.
Avoid concurrent shell calls, repeated command cancellation, and very large command output until the cleanup path is fixed.
Do not restart or terminate DWM or the WMI service as a workaround.

Related reports

Privacy note

This report intentionally excludes the Windows username, full local paths, conversation contents, prompts, repository names, raw Codex databases, and complete log files. Sanitized counter output and selected WMI/DWM event records can be provided if maintainers request them.

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

[Windows 10] DWM Composition handles accumulate after Codex tasks with tool calls #33192

Powered by Codex Action

Reproduced on another system: Windows 11 Pro (build 26200), 32-thread CPU, 64 GB RAM, and NVMe storage. The Desktop app updated twice during the session via the in-app prompt (26.707.9981 -> 26.715.2305 -> 26.715.3651; command-runner 0.145.0-alpha.18). The behavior was unchanged across all three versions.

Observed process-creation rate while a single agent turn was active (PID-diffing Get-Process every 400 ms; therefore a lower bound because shorter-lived processes can be missed):

315-1,022 newly observed PIDs per 8-15 second window, or approximately 40-70 observed process creations/second sustained
One 15-second window contained 467 conhost, 339 taskkill /pid <pid> /t /f, and 169 git processes, plus PowerShell/CMD helpers
Parent sampling via Win32_Process.ParentProcessId showed that the observed taskkill and git children were overwhelmingly parented by ChatGPT.exe

System impact during affected periods:

WmiPrvSE.exe sustained 20-26% whole-machine CPU on this 32-thread system (approximately 6.5-8 logical cores) while the process storm and repeated Win32_Process tree queries were occurring. It also reached approximately 11,000 page faults/second.
System-wide input latency reached multiple seconds on a wired keyboard, and window switching became slow even though total CPU was 37-73%, disk queue was approximately zero, and about half the RAM remained free. This looked like process/console-window churn rather than conventional CPU, disk, or memory exhaustion.
Microsoft Defender added further load during the storm; MsMpEng consumed approximately another 1-3 logical cores. This is consistent with the Defender behavior reported in #30527 and #33875.
Control experiment: terminating ChatGPT.exe reduced observed spawning from approximately 45/second to approximately 0.4/second and WmiPrvSE CPU from approximately 25% to 0.3% immediately.

The parent-attribution sampler itself used Win32_Process, so it could contribute some WMI work. I therefore treat the simultaneous WMI load and process storm as correlation rather than attributing every query to taskkill. The immediate control-experiment drop nevertheless strongly associates the overall load with the active Desktop session.

Amplifier: workspace tracking of untracked build caches (consistent with #32113):

The workspace tracker invoked:

git -c core.hooksPath=NUL -c core.fsmonitor= hash-object -- <file>

as a separate git process for each untracked file. A repository containing untracked .gocache/ directories with 2,274 and 944 files was rehashed file by file on repeated sweeps. Adding .gocache/ to .git/info/exclude roughly halved the observed git spawn rate. Large untracked trees such as build caches, node_modules variants, or Unity Library directories may therefore amplify the problem substantially.

Per-command overhead: %USERPROFILE%\.codex\.sandbox\sandbox.*.log showed a setup refresh (including codex-windows-sandbox-setup.exe), a read-ACL pass, and a command-runner helper copy for each command. Even a trivial one-line read consequently involved approximately 10 observed processes including console hosts and the subsequent taskkill tree cleanup.

Possible mitigation directions, in likely impact order:

Consider native process-lifetime management such as Windows Job Objects instead of invoking taskkill /t /f for each cleanup, if compatible with the sandbox architecture.
Reuse a persistent worker/console rather than starting a fresh PowerShell, console host, and sandbox refresh for every command.
Have workspace tracking apply Git ignore/exclusion rules before hashing and batch paths through hash-object (for example, using --stdin-paths).
Throttle, scope, or remove the approximately once-per-second full-process WMI poll reported in #25453.

Source-level root cause and the 26.707 -> 26.715 regression boundary

I performed a read-only inspection of the installed Windows Desktop bundle and correlated it with local Codex logs and live process snapshots. No prompt content, repository names, private paths, or credentials are included below.

Inspected build: MSIX 26.715.3651.0, internal Electron app 26.715.31251 (build 5538), bundled app-server 0.145.0-alpha.18.

This is not merely "too many Git processes." The current Desktop build contains a closed feedback loop with four components.

1. Git cancellation invokes an unbounded process-tree kill

The installed app bundle's Windows cleanup path is equivalent to:

await execFile(
  path.join(systemRoot, "System32", "taskkill.exe"),
  ["/pid", String(pid), "/t", "/f"],
  { env, windowsHide: true }
);

There is no timeout, no single-flight guard, no creation-time/process-identity check, and no upper bound on concurrent cleanup helpers. The host awaits this cleanup promise.

The local Git host enables tree cleanup for Git commands, whose normal default timeout is 60 seconds. Therefore every timeout or cancellation can create another unbounded taskkill.exe /PID ... /T /F process.

2. The live review query creates and cancels per-file Git subprocesses

The Desktop worker keeps live review-summary/status-summary queries subscribed to working-tree, index, HEAD, and config invalidations. The review summary includes untracked files by default.

For untracked metadata, the current worker processes up to 8 files concurrently and runs a separate command for each ordinary file:

git hash-object -- <path>

It can also run a per-file no-index diff. Rapid invalidation or cancellation therefore fans out Git children, and each cancellation enters the taskkill path above. Local logs show review-summary as the request kind and thousands of aborted Git commands/hash-object calls.

This is the primary producer.

3. PID-only /T cleanup becomes a self-sustaining cross-kill loop

In a live sample of 120 taskkill processes created over about 34 seconds:

105 target PIDs had already exited.
7 target PIDs had already been reused by taskkill.exe.
7 had been reused by conhost.exe.
1 belonged to git.exe.

This is direct evidence that stale PID-only cleanup races with PID reuse. The /T helpers begin terminating cleanup helpers and console hosts spawned by other cleanup attempts. That converts ordinary cancellation churn into a feedback loop.

An independent bounded Toolhelp/.NET cleanup, which did not invoke taskkill, removed 325 taskkill processes, 164 conhosts, and 10 Git processes in one pass and brought taskkill to zero. Re-entering an active affected Desktop task had previously recreated hundreds of helpers, confirming that the Desktop process lifecycle is the active producer rather than Windows spontaneously generating them.

4. Full-machine CIM sampling amplifies the loop into an OS freeze

The child-process snapshot worker first runs a full:

Get-CimInstance Win32_Process

It then queries Win32_PerfFormattedData_PerfProc_Process plus PID-filtered Win32_Process data in batches. A heartbeat runs every 30 seconds, while renderer/event-triggered requests can run with only a 5-second minimum interval. A new worker is created for each snapshot.

Once process count explodes, every sample scans a rapidly changing machine-wide PID set. Timed-out clients and quota failures then add CPU, process, thread, handle, and WMI pressure. This explains the observed "out of memory" condition while about 16.8 GB of physical RAM remained free: the exhausted resources were process/thread/handle/WMI quotas, not RAM capacity.

5. The process registry is not crash-safe

chat_processes.json is loaded with JSON.parse and malformed/all-NUL content is not recovered (other than ENOENT). Records may persist with osPid:null. Updates are written directly with writeFile(JSON.stringify(...)); there is no temporary file, fsync, atomic rename, or last-known-good recovery.

That matches the all-NUL corruption already reported in #29593 and can carry bad lifecycle state across sessions.

Local version boundary

These are aggregate markers from local Desktop logs; session lengths differ, so the table is a regression boundary, not a normalized benchmark:

Desktop version	Sessions	Snapshot failures	WMI quota markers	hash-object calls
26.707.9981	9	69	0	0
26.707.12708	2	57	0	0
26.715.2236	1	54	164	22
26.715.2305	6	3,831	8,632	2,697
26.715.3651	6	614	1,604	156

The unsafe process-lifecycle design predates 26.715, as this issue and older reports demonstrate. However, the catastrophic WMI-quota/freeze regime begins sharply at the 26.707 -> 26.715 boundary on this machine. The recent update is therefore the severity amplifier/regression boundary, even if it did not invent the original bug.

The public CLI changed from app-server 0.144.5 to 0.145.0-alpha.18 in the same boundary. Public commit 6ad0e94 (#32106) raises ancestor-probe concurrency from 8 to 256, which may add startup pressure, but it is not the direct taskkill source. The Electron/Desktop host source and its update diff are absent from the public repository, so identifying the exact private Desktop commit requires OpenAI to inspect its internal 26.707 -> 26.715 diff. The installed current bundle is sufficient to prove the faulty call chain above.

Required remediation

Immediate mitigation: stop or roll back the affected Windows rollout; disable live per-file review fanout and machine-wide CIM sampling until bounded implementations ship.
Replace taskkill /T with a Windows Job Object or bounded Toolhelp traversal. Bind cleanup to PID plus creation time/process handle, not PID alone.
Add a hard timeout, concurrency limit, deduplication, and single-flight semantics to cleanup. Never await a cleanup helper indefinitely.
Coalesce working-tree invalidations and batch Git paths. Do not spawn one Git process per untracked file.
Replace full-machine WMI polling with Job Object accounting, Toolhelp, ETW, or direct process handles scoped to owned children.
Write the process registry atomically with temp-file + flush + rename, validate it on load, and recover from a last-known-good copy.
Add a Windows soak/release-gate test that asserts bounded process creation, cleanup latency, handles, threads, and WMI activity under rapid Git invalidation and cancellation.

Release and ownership concern

This is not an acceptable application failure mode. A coding tool must not be able to hard-freeze the host OS and force repeated power cycles while free memory remains. The architectural warning signs were reported separately for months in #17229, #25453, #26812, #29593, #32113, and #32562. The canonical P0 candidate and multiple precursor issues currently have no public assignee or milestone.

Shipping 26.715 without an end-to-end Windows process-churn soak test turned known defects into a system-wide feedback loop. That is a failure of OpenAI's Codex Desktop maintenance and release process, not an individual contributor problem. OpenAI also does not publish the Desktop host source and its CONTRIBUTING policy rejects unsolicited implementation PRs, so OpenAI cannot reasonably shift responsibility for the fix to affected users.

Please assign an owner, publish a mitigation/rollback, pause the affected Windows rollout, and treat this as a release blocker/P0 candidate. I am available to validate a patched build immediately.

Exact regression boundary: build 5484, Git review metadata worker

I narrowed the recent severity regression to a specific production build and shipped bundle file. This refines my previous comment: the unsafe taskkill /T /F, full CIM sampler, and non-atomic chat_processes.json design already existed, but build 5484 added the high-rate Git subprocess producer that can drive those old defects into a system-wide process/WMI storm.

Reproducible four-build comparison

Source: OpenAI's official production appcast: https://persistent.oaistatic.com/codex-app-prod/appcast.xml

I used HTTP Range requests to extract only resources/app.asar from the official ZIPs, parsed each ASAR header, and hashed/searched the relevant bundled files. The build 5488 ASAR SHA-256 independently matches the published distribution hash, and the relevant build 5538 entry hashes exactly match my currently installed Windows package.

Build	Internal version	Windows package mapping	`.vite/build/worker.js` SHA-256	New per-file review metadata path
5440	26.707.91948	prior 26.707 package	`cae41298ee5d729ff00c5a72ae9edb6c767fb6e71139c0d6d62371a5900af387`	Absent
5484	26.715.21316	26.715.2236.0	`6fccaf96a129f3b8299793a90ddea15442d8af8a54826faa384ee525da4dae27`	First present
5488	26.715.21425	26.715.2305.0	`6fccaf96a129f3b8299793a90ddea15442d8af8a54826faa384ee525da4dae27`	Present; byte-identical to 5484
5538	26.715.31251	26.715.3651.0	`8b4855f500ea4f37df95b41122594c4c3e92bee83c968b49b75419a635bdb540`	Still present

The Windows package/build mappings above come from Codex's own local startup logs (reported internal release version and Sparkle build number).

What changed in build 5484

Build 5440 already contains the review-summary feature, taskkill.exe, Get-CimInstance Win32_Process, and chat_processes.json. However, its worker contains none of these strings:

review-working-tree-file-metadata
Failed to hash working-tree file
Failed to read untracked Git metadata
hash-object

All four first appear in build 5484 inside .vite/build/worker.js. The new implementation walks untracked and zero-OID working-tree entries with a concurrency limit of 8 and, per file, launches operations equivalent to:

git hash-object -- <path>
git diff --no-index --raw --numstat -z -- /dev/null <path>

In build 5484/5488 these are located around minified lines 184, 188, and 190. The review-summary signal count in this worker also rises from 9 occurrences in build 5440 to 18 in build 5484.

That new per-file subprocess fan-out feeds an existing unsafe cancellation path. The local Git host uses killProcessTree: true; cancellation reaches:

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

The cleanup call has no timeout, no single-flight/coalescing guard, and no process-identity check before killing a potentially reused PID. At the same time, the child-process snapshot worker performs full CIM process/performance queries. Under rapid repo-watch invalidation, the combination is capable of producing exactly the observed feedback loop: many short-lived Git children, many tree-kill cleanups, and WMI query quota exhaustion.

Exact current shipped files (build 5538)

app.asar/.vite/build/worker.js
SHA-256 8b4855f500ea4f37df95b41122594c4c3e92bee83c968b49b75419a635bdb540
hash-object: line 184 col 693 and line 190 col 62
review-working-tree-file-metadata: line 188 col 7078
app.asar/.vite/build/src-tv6ZWK8o.js
SHA-256 8a07ef9ad8a2643b9812341c0ba7c770803664bd1c473f8603b837084f86d72c
taskkill.exe: line 771 col 5661
app.asar/.vite/build/child-process-snapshot-worker.js
SHA-256 5fb99e4f2f053613676958cecebacb24401f37cee5bbc294708ec280793cb47c
full CIM/perf query block: line 96

The production ASAR omits the source maps, so the original TypeScript path is not directly recoverable from the official artifact. An unaffiliated reverse-engineered older bundle maps this logic with high confidence to:

main/workers/git-worker-review/metadata.ts
main/workers/git-worker-request-dispatcher.ts
main/workers/git-worker-repo-watch.ts
main/workers/worker-execution-host-client.ts
main/workers/child-process-snapshot-worker.ts

Reference only (not an official source tree): https://github.com/JimLiu/decode-codex/tree/6fd43d66ccad32c9c1ab83b9704e0bbbbf2d4c7b/restored/main/workers

Requested maintainer action

Please diff internal build 5440 -> 5484 for main/workers/git-worker-review/metadata.ts first. Revert or batch the new per-file subprocess path, coalesce repo-watch invalidations, and bound the queue globally. Independently harden process cleanup with single-flight, timeout, PID identity verification, and a strict cap; make the process registry atomic and corruption-tolerant.

This is a release-safety failure across interacting subsystems, not evidence against any individual developer. The key actionable boundary is now specific: build 5484, Git review metadata worker.

Additional clean-reboot reproduction on 26.715.3651.0

I reproduced the same failure on another Windows system after a full reboot. This confirms that the process storm is recreated by a new Codex Desktop session rather than being leftover state from the previous boot.

Environment

Windows build 26200.8875 (25H2), x64
AMD Ryzen 9 7945HX, 32 logical processors
64 GB RAM
Codex Desktop MSIX: OpenAI.Codex_26.715.3651.0_x64__2p2nqsd0c76g0
Bundled ChatGPT.exe / Chromium version: 150.0.7871.124

Clean-reboot reproduction

Fully reboot Windows.
Launch Codex Desktop.
Open one local thread and run read-only shell diagnostics. Some WMI/CIM-based commands timed out.
Inspect the process tree approximately 7.5 minutes after Codex launched (system uptime: 12 minutes 29 seconds).

A six-second snapshot produced:

Metric	First sample	Six seconds later
Total processes	815	809
`taskkill.exe`	223	220
`conhost.exe`	230	228
`ChatGPT.exe`	8	8
Total handles	250,518	249,684
Total threads	11,821	11,810

The overwhelming majority of the live taskkill.exe instances were direct children of the Codex Desktop main process, ChatGPT.exe PID 33116. Of the live console hosts, 214 had taskkill.exe as their direct parent.

The process groups accounted for approximately:

taskkill.exe: 219 instances, 2.97 GiB aggregate working set, 36,684 handles
conhost.exe: 227 instances, 1.72 GiB aggregate working set, 22,445 handles

Creation timestamps showed continuous accumulation from about one minute after Codex startup through the next several minutes.

Desktop log evidence

The previous affected run's Codex Desktop log repeatedly recorded:

[electron-sampler] Failed to collect child process snapshot
Command failed: powershell.exe -NoProfile -NonInteractive -Command
$ErrorActionPreference = 'Stop';
Get-CimInstance Win32_Process |
  Select-Object ProcessId,ParentProcessId |
  ConvertTo-Json -Depth 2

The same log also contains failures from BundledPluginsMarketplace while executing a heavier process/performance snapshot based on Win32_PerfFormattedData_PerfProc_Process and Win32_Process.

This evidence is consistent with the reported feedback loop: process-tree sampling fails or stalls, cleanup launches taskkill.exe /T /F, the cleanup processes and their console hosts accumulate, and subsequent full-machine process enumeration becomes increasingly expensive. The direct parent chain establishes that the cleanup processes originate from Codex; source-level confirmation of the exact retry path still requires maintainer inspection.

A previous manual cleanup reduced the machine from approximately 971 processes to 445, but after a clean reboot and relaunch the same condition returned within minutes.

No raw logs, usernames, repository names, conversation contents, or local paths are included here. I can provide additional sanitized counters if maintainers need a specific capture.

Additional reproduction on Windows 10.0.26200 x64 with Codex Desktop
OpenAI.Codex 26.715.2305.0.

Native 50 ms process sampling reproduced:

ChatGPT.exe -> powershell.exe -> conhost.exe
approximately 100 process births/minute
median lifetime approximately 1.43 seconds

A severe cleanup recurrence reached:

215 taskkill.exe processes directly owned by ChatGPT.exe
224 conhost.exe processes
approximately 4.3 GiB combined working set
998 WMI Event 5858 failures in 15 minutes

The packaged app.asar child-process snapshot worker executes the matching
Get-CimInstance Win32_Process / Win32_PerfFormattedData_PerfProc_Process
PowerShell probes. Cockpit Tools was separately stopped and remained absent;
the ChatGPT-owned taskkill/WMI storm still reproduced, so this is not caused
by the local Wiki scripts or Cockpit.

A bounded local mitigation used native Toolhelp snapshots, PID+creation-time
identity, a 10-second age gate and two-snapshot parent-lineage verification.
A one-shot watcher was falsified because births continued after its first
containment. The corrected multi-round watcher made 17 containment attempts,
stopped 284 lineage-verified taskkill processes, never directly stopped
conhost/PowerShell/cmd/ChatGPT, and reached 10 consecutive zero-taskkill
samples. This only mitigates accumulation; it does not prevent upstream births.

Requested upstream fixes:

Replace per-sample PowerShell/WMI spawning with a persistent or native helper.
Coalesce sampling and add rate limiting/backoff/circuit breaking.
Correctly reap taskkill/conhost cleanup children and stop retry amplification.
Provide a supported diagnostic/telemetry sampling disable switch.

Correction: exact direct-parent boundary, two independent defects, and maintainer source anchors

I downloaded and compared the complete worker.js files for build 4559 and its direct child build 5059. This corrects two statements in my earlier comments:

Build 5484 is not the first introduction of the core producer/cleanup chain. It adds the later per-file metadata amplifier, but the complete unsafe chain first appears in the publicly recoverable direct-parent boundary 4559 -> 5059.
Saying there was "no single-flight guard" was too broad. There is per-original-child single flight (cleanupPromise ??=). What is absent is a global cleanup limit/coalescer, timeout, circuit breaker, and PID identity validation.

Direct-parent comparison: JimLiu/decode-codex@54c373f...fa0ef1d

Build 4559 (26.623.70822): https://github.com/JimLiu/decode-codex/blob/54c373f781d0ee51f0c16f58ec349ae97a16f941/ref/.vite/build/worker.js
Build 5059 (26.707.31428): https://github.com/JimLiu/decode-codex/blob/fa0ef1d8be41adc202d1f92e80cf1937f59ae45a/ref/.vite/build/worker.js

That repository is an unaffiliated snapshot, not an official source tree. The direct-parent bundle diff is the evidence; OpenAI should verify the corresponding private-source commit internally.

Defect A: the producer continuously creates cleanup work

At build 4559, worker.js:61466 is:

child = await host.spawn({ args, cwd, env });

At build 5059, worker.js:61718 becomes:

child = await host.spawn({
  args,
  cwd,
  env,
  killProcessTree: true,
});

Build 5059 also introduces this review-snapshot cancellation path at lines 64904-65069:

class GitReviewSnapshot {
  abortController = new AbortController();
  signal = this.abortController.signal;

  retire() {
    if (!this.signal.aborted) {
      this.abortController.abort();
      this.removeRetiredStoreWhenIdle();
    }
  }

  commandOptions(options, objectStoreEnv) {
    return {
      ...options,
      env: { ...objectStoreEnv, ...options.env },
      signal:
        options.signal == null
          ? this.signal
          : AbortSignal.any([this.signal, options.signal]),
    };
  }
}

invalidateGitReadCachesForRepoChange(changeType, changedPaths) {
  this.gitReadGenerationValue += 1;
  this.advanceReviewSnapshot();
  invalidateQueriesForRepoChange(/* ... */);
}

advanceReviewSnapshot() {
  const previous = this.reviewSnapshotValue;
  this.reviewSnapshotValue = new GitReviewSnapshot(this, previous.generation + 1);
  previous.retire();
}

The live-query loop at lines 70578-70640 keeps a dirty flag while a request is in flight and schedules another refresh in finally. review-summary reacts to working-tree changes at lines 70669-70677. The repo-event handler at lines 72343-72348 both advances/aborts the review snapshot and calls liveQueryRegistry.handleRepoChanged(...).

Therefore repository churn repeatedly aborts active Git children; each distinct child has opted into process-tree cleanup. Build 5484 later increases the rate with per-file hash-object / no-index metadata work, but it is an amplifier, not the origin.

Defect B: PID-only `/T` cleanup does not converge

Build 4559 lines 64163-64198 simply call the existing child kill method. Build 5059 lines 64529-64715 add the following code (identifiers expanded for readability, control flow unchanged):

const execFileAsync = promisify(childProcess.execFile);

function wrapChild(child, stdout, stderr, timeout, killTree = async () => child.kill()) {
  let cleanupPromise = null;

  const kill = () => {
    if (timeout != null) clearTimeout(timeout);
    cleanupPromise ??= killTree().catch((error) => {
      try {
        child.kill("SIGKILL");
      } catch {}
      throw error;
    });
    cleanupPromise.catch(() => {});
  };

  const waitPromise = child.wait().then(async (result) => {
    await cleanupPromise;
    // close streams and return result
    return result;
  });

  return { kill, wait: () => waitPromise /* ... */ };
}

async function killProcessTree(child) {
  const pid = child.getPid();
  if (pid == null) {
    child.kill("SIGKILL");
    return;
  }

  if (process.platform === "win32") {
    const systemRoot = process.env.SystemRoot ?? process.env.windir ?? "C:\\Windows";
    await execFileAsync(
      path.win32.join(systemRoot, "System32", "taskkill.exe"),
      ["/pid", String(pid), "/t", "/f"],
      { env, windowsHide: true },
    );
  }
}

wrapped = wrapChild(
  child,
  stdout,
  stderr,
  timeout,
  options.killProcessTree ? () => killProcessTree(child) : undefined,
);

The call stores only a numeric PID. It has no process handle/creation-time identity check, no timeout or abort signal, and no global concurrency bound. The host awaits that helper indefinitely.

This second defect must not be conflated with the producer. taskkill.exe does not itself spawn another taskkill.exe, and this is not literal JavaScript recursion. The recursion/cross-kill occurs in Windows /T tree traversal after stale PIDs are reused by peer taskkill.exe or conhost.exe processes. Defect A supplies new helpers; Defect B collapses completion throughput. While A remains active, live helpers = births - completions grows without bound.

Maintainer source-search anchors

The production bundles reference worker.js.map, but the source maps are omitted. The following unique strings and restored-module boundaries should take an internal maintainer directly to the private TypeScript:

main/workers/worker-execution-host-client.ts: search taskkill.exe, Local execution host processes do not support resizing, and killProcessTree.
main/workers/git-worker-commands.ts: search git process aborted and the host.spawn(... killProcessTree: true) call.
Review repository/snapshot owner: search GitReviewSnapshotStaleError, Git snapshot became stale, advanceReviewSnapshot, and invalidateGitReadCachesForRepoChange.
main/workers/git-worker-repo-watch.ts: search scheduleRepoChanged and Git repo changed.
main/workers/git-worker-request-dispatcher.ts / live-query registry: search subscribe-live-query, git-live-query-updated, handleRepoChanged, and review-summary.
main/workers/git-worker-review/metadata.ts (5484+ amplifier): search review-working-tree-file-metadata, Failed to hash working-tree file, hash-object, and Failed to read untracked Git metadata.

Current official build 5538 still contains the same path:

.vite/build/src-tv6ZWK8o.js line 771, column 5661: taskkill.exe;
.vite/build/src-tv6ZWK8o.js line 750, column 41972: Git killProcessTree:true;
.vite/build/worker.js line 181, column 62314: GitReviewSnapshotStaleError;
.vite/build/worker.js line 184, column 693 and line 190, column 62: per-file hash-object;
.vite/build/worker.js line 188, column 7078: review-working-tree-file-metadata.

Fresh reproduction separating the two defects

While the affected Desktop task remained active during this investigation, live taskkill.exe count jumped from 0 to 278. A bounded direct, non-tree termination pass against only taskkill.exe could not settle: after 80 samples it still oscillated at 2-3 because new helpers were being created. A second bounded pass that stopped active Git children and existing taskkill helpers (without /T) reached 15 consecutive zero/zero Git/taskkill samples; a delayed five-second check remained zero/zero.

This directly separates the active Git producer from the non-convergent cleanup backlog.

Separate but related release-quality failure: large-conversation UI loading

The same release process is repeatedly shipping an avoidable full-history hydration/rendering problem:

[Windows Desktop 26.707.8479.0] New windows still fan out full conversation snapshots for every streaming thread #32722 contains production-bundle evidence that a newly connected window iterates every entry in streamingConversations and broadcasts the complete conversationState, including loaded turn history. It serializes the entire message before applying a 256 MiB limit, so even dropped payloads incur construction, serialization, allocation, and copying cost.
Codex Desktop becomes extremely sluggish when opening very large local thread on Windows #25390 reproduces a nearly frozen Desktop UI with a 242.5 MB / 50,589-line local thread.
Desktop performance collapses in profiles with a few very large local conversation histories (typing, scrolling, thread list, random exits) #18693 provides an A/B profile test where restoring only a few giant histories (roughly 455 MB to 1.8 GB each) makes typing, scrolling, switching, and the thread list slow again.
Codex Desktop becomes unresponsive when opening previous conversations; thread history loading appears too eager #29590 shows eager resume/hydration stalls at much smaller history sizes.
Windows Codex Desktop 26.715.2305.0 hangs while rendering ~200 KB tool output #33822 shows the current 26.715 renderer can hang on only about 200 KB of streamed tool output while emitting a high-rate ResizeObserver loop.

These reports are all open. The remedy is conventional application engineering, not an unsolved research problem: send metadata plus a bounded recent tail, page older turns, virtualize rendered rows, keep large image/base64/tool payloads off the critical path, apply byte/count gates before serialization, and add backpressure/cancellation when switching threads.

It is not publicly knowable which internal OpenAI department is supposed to supervise this. What is publicly observable is that this P0 candidate still has no assignee, the unsafe process code has shipped from build 5059 through current build 5538, and multiple source-backed large-history reports remain open while the same unbounded paths continue shipping.

That is a release-governance and cross-subsystem ownership failure. A Windows Desktop release gate should cover both:

rapid Git invalidation/cancellation with assertions on process births, cleanup convergence, PID identity, handles, threads, and WMI activity;
opening/switching multi-hundred-megabyte histories with bounded serialized bytes, renderer nodes, memory, CPU, and time-to-first-visible-turn.

Please assign explicit owners for process lifecycle and conversation hydration, publish the affected/fixed build boundary, and treat failure of either soak test as a release blocker.

Controlled A/B isolation: the Desktop child-process snapshot sampler triggers the WMI CPU storm

This is a follow-up to #33776 with a controlled isolation result from the currently shipped Windows build.

Environment

Windows x64, build 26200.8875 (25H2)
32 logical processors
Codex Desktop MSIX: OpenAI.Codex_26.715.3651.0_x64__2p2nqsd0c76g0
Observation date: 2026-07-18 (UTC+08:00)

Confirmed observations before the intervention

The updated 26.715.3651.0 build still reproduced the failure. Within roughly 20 seconds of a fresh Codex session, 22 taskkill.exe processes accumulated and WmiPrvSE.exe reached a raw per-process processor-time reading of about 1527% (about 47.7% of a 32-logical-processor machine). A separate Task Manager capture reached 71.2% whole-machine CPU for one WMI Provider Host.
Microsoft-Windows-WMI-Activity/Operational showed repeated Win32_Process and Win32_PerfFormattedData_PerfProc_Process work. Representative failures were 0x800706BA with Could not send status to client, consistent with the short-lived PowerShell client exiting while WMI work was still active.
Process-creation auditing attributed the WMI client PowerShell processes to the main Codex Desktop ChatGPT.exe process.
Read-only inspection of the shipped bundle found .vite/build/child-process-snapshot-worker.js and its sampler manager. On Windows, the worker runs a PowerShell sequence equivalent to:
1. Get-CimInstance Win32_Process to collect PID/parent relationships;
2. Get-CimInstance Win32_PerfFormattedData_PerfProc_Process to collect per-process CPU data;
3. a large PID-filtered Get-CimInstance Win32_Process -Filter "ProcessId = ... OR ..." query for details.
The PowerShell request has a 5-second timeout. The sampler manager also has a 30-second focused heartbeat and allows non-heartbeat triggers at a 5-second minimum interval. The shipped build exposes no supported switch that disables this sampler.

Controlled intervention and result

As a diagnostic isolation test, the legacy Windows PerfProc provider was disabled with:

lodctr /d:PerfProc

Stale WmiPrvSE.exe and already accumulated taskkill.exe processes were stopped once after the provider change.

The same probe used by the sampler then failed fast with Invalid class in approximately 748 ms:

$ErrorActionPreference = 'Stop'
Get-CimInstance Win32_PerfFormattedData_PerfProc_Process

Because the shipped worker sets $ErrorActionPreference = 'Stop' and issues the PerfProc query before the large PID-filtered detail query, the failure aborts the snapshot command before the expensive follow-up query runs.

After one complete 39-second observation window:

system-wide taskkill.exe count: 0;
maximum sampled WMI-host CPU: 0.05% of the whole machine;
no renewed WMI runaway was observed.

A later live check on the same active Codex session still showed:

taskkill.exe: 0 system-wide;
PerfProc: disabled;
no WMI CPU recurrence.

This is a strong A/B result that isolates the child-process snapshot path as the trigger for the WMI CPU component. It does not prove that every taskkill.exe cleanup defect has the same internal cause; the cleanup backlog and the WMI sampler should remain separately fixable defects.

Important limitation

Disabling PerfProc is a machine-wide, reversible diagnostic workaround, not a product-level fix and not a suitable general recommendation. It makes legacy per-process performance-counter/WMI classes unavailable. It can be restored with:

lodctr /e:PerfProc

The installed Codex package was not modified. The upstream sampler still runs and still needs a real fix.

Requested upstream changes

Add a supported emergency switch to disable child-process snapshot sampling on Windows.
Replace repeated PowerShell/WMI full-machine polling with a persistent native helper, Toolhelp/process handles, or Windows Job Objects scoped to Codex-owned descendants.
On timeout, cancel and await the underlying WMI work rather than only terminating the client process.
Enforce single-flight/backpressure, a hard concurrency cap, deduplication, and exponential backoff.
Bound the PID set and avoid giant OR filters against Win32_Process.
Add a Windows release-gate soak test that asserts bounded WMI CPU, process births, cleanup latency, and helper counts under focus changes, long tasks, cancellation, and large descendant trees.

Claim boundary

Confirmed: Codex Desktop starts the matching PowerShell/WMI sampler; the current build still contains it; the failure reproduced on the current build; blocking its first expensive PerfProc query eliminated the observed WMI runaway and taskkill accumulation during the validation windows.
Strong inference: the 5-second client timeout without effective cancellation/backpressure allows WMI work to overlap after clients exit, producing the 0x800706BA client-gone failures and runaway CPU.
Not claimed: disabling PerfProc is a root fix, or that all Codex child processes were zombies. Most of the earlier 216 descendants were live Codex/MCP/Node/Python components; the clearly abnormal residue was the accumulating cleanup helpers and overlapping WMI workers.

Temporary mitigation for affected Windows users: Codex Process Guard

For developers who already updated Codex Desktop and are hitting the taskkill.exe / conhost.exe process storm, I published a small independent emergency guard:

https://github.com/BIOcanse/CodexProcessGuard

It uses native Toolhelp snapshots plus PID creation-time and ancestry validation to contain only verified Codex-owned cleanup helpers and directly owned Git processes. It does not patch Codex or eliminate the upstream producer bug; it limits the runaway resource storm so affected developers can keep using Codex while OpenAI prepares a proper fix.

The current release supports Windows 10/11 x64, requires no administrator rights or separate .NET installation, and fails closed if the expected Codex package ancestry cannot be verified. Please read the README and verify the published SHA-256 before running the unsigned binary.

Latest release: https://github.com/BIOcanse/CodexProcessGuard/releases/latest

Diagnostic update: the Git child-process timeout precedes the `taskkill` / WMI storm

I need to correct an earlier working hypothesis: clearing the sidebar/workspace history does not fix this problem. I rolled back that isolation change and restored the original state. The state database passes quick_check, and the failure still reproduces even when startup work is reduced to only one or two repositories.

Testing again with Codex Desktop 26.715.4045.0 narrows the failure boundary further:

The Desktop UI itself becomes visible in roughly 2–3 seconds.
The background sidebar_workspace_task_groups_task_dirs / Git-origin discovery work starts.
Git commands launched through the Desktop process environment hang until a fixed 60,000 ms timeout.
The same commands, against the same repositories, finish in 31–152 ms when run directly from PowerShell. A Node execFile control test also completes normally.
After the timeout, Desktop invokes:
```
taskkill.exe /pid <pid> /t /f
```
Concurrent timeouts, cancellations, retries, and process-tree cleanup then produce the taskkill → WMI process enumeration → further cancellation storm described in the original report. Eventually internal RPCs and the main window stop responding.

Additional exclusion tests:

Reducing sidebar/history data lowers the number of Git scans, but the remaining one or two scans still hang for the full 60 seconds. History size is an amplifier, not the initial cause.
The repositories are healthy; the same Git commands complete normally outside Desktop.
Direct Win32_Process / performance-process WMI queries complete normally outside Desktop (roughly 0.7–1.0 seconds). WMI amplifies the cleanup storm but is not the initial trigger.
This is not caused by auto-review or approval configuration.
There is no documented configuration switch that fully disables the startup Git-origin scan.
Other app-server requests such as model/config/plugin status reads also become delayed by approximately 60 seconds once the failure begins, consistent with a blocked process-management/RPC path.

Revised working diagnosis

The evidence now points to a Windows-specific defect in the Desktop wrapper's Git child-process lifecycle path: spawn, stdout/stderr completion, cancellation, or reaping. A single Git subprocess that does not complete correctly is amplified by concurrent, unbounded taskkill /T cleanup into the visible process/WMI storm and application hang.

This is the narrowest boundary that can be established without OpenAI's source, private symbols, or an internal trace. The exact lock or failing code path still requires maintainer-side instrumentation.

Requested fix / instrumentation

Please investigate the Windows Desktop child-process wrapper used by Git-origin discovery, especially:

why a Git process that exits in milliseconds outside Desktop is observed as running until the 60-second timeout inside Desktop;
whether stdout/stderr or process-exit completion can be lost;
bounded concurrency and deduplication for repository discovery;
cancellation/reaping without launching an independent taskkill.exe tree for every timed-out command;
use of Windows Job Objects or another bounded process-tree cleanup mechanism;
telemetry around spawn time, child PID, pipe closure, exit notification, cancellation, and cleanup completion.

A full Windows restart temporarily clears the accumulated process/IPC state, so Desktop works for roughly 10–20 minutes before the cycle starts again. This explains why rebooting appears to help but does not resolve the defect.

I can provide sanitized timestamps and selected logs privately if maintainers need them.

Analysis (community)

Narrow residual only for the OSS goal / rollout-scan path that compounds large-thread pain on Windows Desktop threads such as #33776 (and related #34929). Under docs/contributing.md — invitation-only. No unsolicited PR.

Important boundary

This comment does not re-litigate the Electron taskkill / WMI storm. That loop is closed Desktop / app.asar territory and is not caused by the OSS path below. The OSS residual is a second, independent cost center: goal set/clear can unconditionally rescan the full legacy JSONL rollout even when SQLite metadata already exists.

Root-cause hypothesis

thread/goal/set and thread/goal/clear always call reconcile_thread_goal_rollout before mutating the goal store. That helper always invokes reconcile_rollout(..., builder=None, items=[]). On the empty-input branch, reconcile_rollout runs metadata::extract_metadata_from_rollout first and only afterwards looks up an existing SQLite thread row — so a fully materialized row cannot short-circuit the JSONL scan.

Verified at HEAD 4c43465133:

1. Caller always reconciles first.
codex-rs/app-server/src/request_processors/thread_goal_processor.rs:

thread_goal_set_inner → reconcile_thread_goal_rollout then set_thread_goal
clear path repeats the same order

2. Helper always full-reconciles with empty items.
reconcile_thread_goal_rollout resolves the rollout path, then:

reconcile_rollout(Some(state_db), path, provider, builder=None, &[], ...)

3. Extract-before-lookup in state_db.
codex-rs/rollout/src/state_db.rs reconcile_rollout empty-input branch: extract_metadata_from_rollout runs before ctx.get_thread(metadata.id). An existing metadata row therefore does not prevent a multi-GB JSONL reread. Community forensics (e.g. ~4 GiB rollout, sustained high codex.exe read bandwidth after WMI workarounds) fit this chain even when the taskkill storm is separately mitigated.

4. Fix surface is small and OSS.
StateRuntime / DB already expose thread row lookup. A pre-extraction fast path (“if metadata row present → mutate goal in SQLite; else slow reconcile”) is structurally available.

Ranked fix outline (OSS only):

Before extract_metadata_from_rollout, probe SQLite for the thread id; if present, skip full JSONL scan for goal set/clear.
Reserve full-rollout reconciliation for migration / missing-row repair only.
Metrics: count full scans vs fast path; log rollout size when scan runs.
Fail-first test: fixture with large JSONL + existing DB row → goal set does not re-read full file.

Again: please keep WMI/taskkill diagnosis on the Desktop side; this is the goal reconciliation residual only. Happy to draft the fast-path patch if maintainers want it. No unsolicited PR.

I observed a very similar system-wide rendering/stuttering issue on Windows.

Environment:

Affected Codex/ChatGPT Desktop build: OpenAI.Codex 26.721.4979.0, x64, Microsoft Store
Windows: x64, version 25H2, build 26200.8875
GPU 1: AMD Radeon 780M Graphics, driver 32.0.21030.2001
GPU 2: NVIDIA GeForce RTX 4060 Laptop GPU, driver 32.0.15.9159
OrayIddDriver virtual display device is also present

Symptoms:

After using Codex Desktop for an extended period, Windows developed severe system-wide visual stuttering.
The most obvious symptom was that dragging any application window became extremely choppy.
Closing the Codex/ChatGPT app did not restore normal rendering performance.
Restarting Windows immediately restored smooth window movement and normal responsiveness.
Before the restart, ChatGPT/Codex-related processes were using roughly 2 GB of memory, but the system still had approximately 13.5 GB of available RAM, so this did not appear to be ordinary memory exhaustion.

After restarting Windows, the app updated to OpenAI.Codex 26.721.11231.0. I have not yet confirmed whether the problem also reproduces on this newer build.

No project contents, conversation data, or private paths are included in this report.

Adding to the performance issues, I've managed to capture a trace purely minutes after starting the app. It has slowly become unusable over the past few days: 019fbd54-7b55-71d1-b2a2-d083a7e5c65c

Independent occurrence with DWM handle accumulation and Windows UI degradation

I observed a similar, although not identical, failure mode on another Windows system during extended Codex Desktop use.

All measurements below were collected locally during this incident. Values from the original issue are not repeated as if they were local measurements.

User-visible impact

After long-running Codex Desktop use, Windows UI responsiveness degraded progressively.

The most severe symptom was window movement: dragging ordinary application windows with the mouse became extremely slow and jerky, making the computer difficult to use.

Additional symptoms included:

slow or unreliable window rendering and switching;
intermittent difficulty loading or interacting with the Codex remote-thread UI;
the background Codex agent could continue running commands and modifying files even while the desktop UI was difficult to operate;
previous occurrences were only reliably cleared by restarting Windows.

This was gradual degradation rather than an immediate application or operating-system crash.

Environment

Windows 10 x64, build family 19045
32 GB physical RAM
12 logical processors
Codex Desktop package version: 26.721.4979.0
Bundled ChatGPT/Chromium executable version: 150.0.7871.128
Approximately 74 hours of system and application uptime at inspection
Native Windows workspace
One or more long-running, tool-heavy Codex sessions

No username, computer name, repository name, project information, file-system path, prompt, credential, or description of the agent's work is included here.

System responsiveness at inspection

The machine was not generally unresponsive and command execution was still fast:

Get-Process: approximately 77 ms
git status: approximately 183 ms
root-directory listing: approximately 63 ms
post-Explorer-restart verification command: approximately 82 ms

Approximately 10 GB of the installed 32 GB RAM was still available before closing VS Code. The system drive had approximately 46% free space.

A two-second CPU sample showed active Node.js worker processes as the primary CPU consumers, consistent with ongoing build or test activity. Codex itself consumed approximately 1% of total CPU during that sample.

This suggests that the desktop degradation was not caused by general CPU saturation, complete physical-memory exhaustion, slow command execution, or a full system drive.

DWM measurements

During the affected state, dwm.exe showed:

approximately 54,600–54,700 handles;
approximately 605–606 MB working set.

Representative readings collected during troubleshooting were:

initial inspection: approximately 54,682 handles;
after force-closing VS Code: approximately 54,672 handles;
after restarting Explorer: approximately 54,648 handles;
after the unsuccessful DWM termination attempts: approximately 54,697 handles.

The DWM handle count remained approximately stable during a short 12-second observation window. This indicates accumulated state rather than a rapidly increasing handle count at the exact moment of inspection.

No healthy post-reboot DWM baseline was recorded during this incident, so this report does not claim a measured before-and-after growth rate.

Application memory

Before mitigation:

Codex process group: approximately 2.0 GB combined working set and 2.1 GB combined private memory;
ChatGPT and ChatGPT Classic processes: approximately 5.1 GB combined working set and 7.3 GB combined private memory;
VS Code process group: approximately 4.74 GB combined working set;
WSL/Docker vmmem: approximately 2.3 GB working set.

Windows Error Reporting had previously recorded RADAR_PRE_LEAK_64 entries for:

ChatGPT Classic.exe;
a node.exe process.

These WER entries are reported as diagnostic observations. They suggest that Windows detected abnormal resource growth, but they do not by themselves establish the root cause of the DWM handle accumulation.

WMI evidence

The Microsoft-Windows-WMI-Activity/Operational event log contained 33 Event ID 5858 failures during the six hours preceding inspection.

Representative failures queried:

Win32_PerfFormattedData_PerfProc_Process

and ended with:

0x800706BA – Could not send status to client

This WMI error signature resembles the one discussed in the original issue, but the local process snapshot was different.

At the time of local inspection:

there was no active taskkill.exe accumulation;
12 conhost.exe processes were present;
no evidence was collected showing hundreds of Codex-owned taskkill.exe or conhost.exe processes.

Therefore, this report does not claim that the exact subprocess-cleanup loop described in the original issue was active on this machine. It may be a related residual state or a different path producing similar WMI and DWM symptoms.

Display and event-log checks

No corresponding evidence was found for:

a DWM crash;
a display-driver reset;
DXGI device loss;
GPU out-of-memory failure;
a resource-exhaustion crash at the time of inspection.

The absence of these events does not rule out Chromium renderer, GPU-surface, handle, or other desktop-resource retention.

Mitigation attempts

Force-closing VS Code

The complete VS Code process group was force-closed with the user's authorization.

Results:

24 Code.exe processes terminated;
no Code.exe process remained;
available physical memory increased from approximately 10.04 GB to 14.22 GB;
approximately 4.18 GB of physical memory was released;
Codex, ChatGPT, and the active background agent remained running;
DWM remained at approximately 54,672 handles and 605 MB.

This shows that VS Code accounted for substantial memory usage but was not solely responsible for the retained DWM state.

Attempting to restart DWM

The exact running DWM process was targeted with:

elevated Stop-Process -Force;
Windows taskkill /F.

Both attempts returned Access denied.

The DWM process remained running and responsive. No SYSTEM-level debugger, protected-process bypass, or other unsafe workaround was attempted because the computer was unattended and losing the graphical session would have been unacceptable.

Restarting Windows Explorer

explorer.exe was terminated and explicitly restarted.

Results:

old Explorer PID: 9576;
new Explorer PID: 21144;
Explorer working set decreased from approximately 169 MB to 54 MB;
Explorer handle count decreased from 2,973 to 655;
the new Explorer process responded normally;
Codex and ChatGPT remained running;
DWM remained effectively unchanged at approximately 54,648 handles and 606 MB.

Restarting Explorer successfully refreshed the Windows shell but did not release the DWM resources.

Full restart

A full Windows restart was not performed during this diagnostic session because a long-running background task was still active.

Historically, restarting Windows has been the only reliable way to restore normal window movement and desktop responsiveness after the degradation becomes severe.

Reproduction pattern

The approximate pattern observed across occurrences is:

Start Codex Desktop on Windows.
Keep one or more tool-heavy Codex sessions active for multiple days.
Repeatedly use shell tools, including concurrent commands, commands with substantial output, cancellations, or timeouts.
Continue working while Codex Desktop, ChatGPT/Chromium renderer processes, Node.js workers, and related development tools remain running.
Windows window movement, switching, rendering, or remote-thread loading gradually becomes slow or unreliable.
Inspect dwm.exe and observe unusually high retained handle and memory values.
Closing large applications or restarting Explorer may release their own resources but does not necessarily restore DWM.
Restarting Windows restores normal behavior temporarily.

The exact operation that initiates the resource retention has not been isolated.

Current assessment and limitations

The local evidence establishes that:

DWM retained approximately 54,600 handles and 605 MB working set;
long-running Codex/ChatGPT and development-tool processes retained several gigabytes of memory;
WER recorded RADAR_PRE_LEAK_64 for ChatGPT Classic and Node.js;
WMI produced repeated Event ID 5858 failures;
closing VS Code and restarting Explorer did not materially reduce DWM resource usage;
Windows UI responsiveness, especially mouse-driven window movement, became severely degraded.

The evidence does not yet establish whether the root cause is:

Codex process cleanup or cancellation;
ChatGPT Classic or another Chromium renderer;
retained graphics or GPU surfaces;
Node.js subprocesses;
a VS Code extension;
a display-driver interaction;
or an interaction between several long-running Electron applications.

The similarity to this issue is significant, especially the WMI failures, elevated DWM resources, progressive Windows UI degradation, and recovery after reboot. However, the absence of an active local taskkill.exe storm means the exact same cleanup defect has not been proven.

Expected behavior

Long-running Codex Desktop sessions should not:

cause unbounded DWM handle or working-set retention;
leave renderer, app-server, console, or process-query resources alive after tool calls complete;
cause repeated failed WMI queries against stale or exited processes;
degrade mouse-driven window movement or general Windows UI responsiveness;
require a complete Windows restart to restore usability.

A supported way to restart Codex renderers and the app-server while preserving thread state would also reduce the impact of this failure mode.

Diagnostic questions

Can Codex Desktop retain process handles, WMI clients, console resources, or Chromium window surfaces even after the originating cleanup subprocesses have exited?
Can a long-running or repeatedly compacted thread keep renderer or app-server resources alive indirectly?
Does Codex Desktop version 26.721.4979.0 include any mitigation for the process-cleanup problem tracked in this issue?
Which counters or logs would best distinguish subprocess-cleanup leakage from Chromium/GPU-surface retention?
Is there a supported way to restart the Codex app-server and renderer processes without terminating active background work or losing thread state?

Feedback correlation

The same incident was submitted through Codex's in-app feedback mechanism.

Feedback session ID:

019fbd40-b02b-7772-b143-122169a00c36

Sanitized counter output and selected Windows event records can be provided if maintainers request them.

Follow-up: after re-enabling sandbox_private_desktop = true on Microsoft Store package 26.727.6591.0, the same Windows-wide DWM/window-dragging degradation began to return during a long session, so the issue does not appear to be fixed in this build.

thanks for the detailed reports and investigation here: they were really helpful 💖

we’ve shipped fixes in 26.730.7989.0 that address some major sources of powershell/wmi storms
taskkill.exe can still be started by other process-cleanup paths, and we’re continuing to work on reducing that separately

if you’re still seeing sustained wmi cpu usage or system-wide lag after 26.730.7989.0, please share an updated /feedback id

@chess-oai

Thanks for the update @chess-oai — confirming the boundary from my earlier comment so the OSS half does not get closed alongside the Desktop half.

My residual was explicitly not the powershell/WMI storm. It is the goal-reconciliation path, which can rescan the full legacy JSONL rollout on every thread/goal/set and thread/goal/clear even when a SQLite metadata row already exists. Re-verified on main today, still unremediated:

codex-rs/app-server/src/request_processors/thread_goal_processor.rs:130 and :248 still call reconcile_thread_goal_rollout before set_thread_goal (:143).
codex-rs/rollout/src/state_db.rs reconcile_rollout (:516) still runs extract_metadata_from_rollout (:543) before ctx.get_thread(metadata.id) (:556), so a fully materialized row cannot short-circuit the scan.

On multi-GB rollouts this surfaces as sustained codex.exe read bandwidth that survives the WMI mitigations — meaning some reporters may still see lag after 26.730.7989.0 from a different cause than the one you fixed, and their /feedback ids would point at disk I/O rather than WMI. Worth keeping in mind when reading the follow-ups you get.

The fast path is small: probe SQLite for the thread id before extraction, and reserve full-rollout reconciliation for migration / missing-row repair. Happy to draft it with the fail-first test (large JSONL + existing DB row → goal set does not re-read the file) if that would be useful — still no unsolicited PR.

@bbingz

@bbingz we have a fix en route for that one as well

@chess-oai

@chess-oai thanks for the update — good to hear a fix is en route for the ChatGPT.exe taskkill/conhost storm. Standing by for the release notes; happy to re-verify on Windows once it ships.

Current-main source follow-up: hook cleanup still has an unreaped `taskkill` fallback

I checked current public source at 77b30a21e17d6ec6317f712ab6d044cb1bd152e7 because a separate Windows long-running Codex incident reached 498 processes / 8,304 threads / 239,618 system-wide handles and later Win32 1816 process-creation failures.

There is a direct source path that matches this report's taskkill.exe / conhost.exe accumulation pattern:

codex-rs/hooks/src/engine/command_runner.rs

impl Drop for ProcessTreeGuard {
    fn drop(&mut self) {
        ...
        #[cfg(windows)]
        {
            if let Some(job) = self.job.as_ref() {
                let _ = job.terminate();
            } else {
                let _ = std::process::Command::new("taskkill")
                    .args(["/PID", &process_id.to_string(), "/T", "/F"])
                    .stdin(Stdio::null())
                    .stdout(Stdio::null())
                    .stderr(Stdio::null())
                    .spawn();
            }
        }
    }
}

The fallback cleanup child is spawned from a Drop implementation and its handle is immediately discarded. There is no wait(), no bounded timeout/reap, and no postcondition that the cleanup subprocess itself exited. On Windows, taskkill.exe can in turn acquire a console host. Repeated fallback cleanup therefore has a plausible direct path to the exact process family reported here.

A second lifecycle detail in the same function is also worth auditing:

// Successfully completed hooks may intentionally leave detached helpers running.
if let Some(job) = process_tree_guard.job.as_ref() {
    let _ = job.preserve_descendants();
}
process_tree_guard.process_id = None;

Preserving descendants may be intentional for hooks whose contract is to launch a resident helper, but the generic successful-hook path does not visibly bind those preserved descendants to a durable owner/lease or later retirement path here. If ordinary hook commands can create helpers accidentally, this can turn successful hook completion into process ownership loss rather than cleanup.

Suggested regressions:

Force the Windows Job Object creation/spawn-contained path to fail so the taskkill fallback is exercised repeatedly; assert no taskkill.exe/conhost.exe accumulation and wait for each cleanup child to terminate.
Repeated hook timeout/cancellation with synthetic child+grandchild trees; require process/handle counts to return to baseline.
Separate explicit resident_detached hook semantics from normal task-owned hooks; only the former should preserve descendants, and preserved processes should have a durable lifecycle owner rather than being anonymously detached.
Long-run Windows hook test followed by a fresh CreateProcess to catch eventual Win32 1816/resource exhaustion.

This is source-level corroboration, not a claim that this one fallback explains every handle/process in the separate incident; the MCP generation leak and sandbox/lsass-handle family can compound the same host-exhaustion symptom.

@chess-oai

Hello @chess-oai,

I am an independent developer based in South Korea, and I use Codex extensively in my daily development work.

I personally use several mini PCs because they offer great value for the money. Some of them have relatively modest hardware specifications, and the Windows version of the ChatGPT Desktop app has been experiencing very noticeable performance issues and lag on these systems.

I have been patiently waiting for improvements to this issue, but it has remained unresolved for quite some time, so I wanted to respectfully ask if the team could take another look at it.

From what I can see, I am not the only person experiencing this problem. A number of other developers have reported similar Windows performance, process cleanup, WMI, and CPU-related issues.

I understand that the team has many issues and priorities to work through, but I would sincerely appreciate it if this Windows performance issue could be given somewhat higher priority.

I have now been waiting for a fix or meaningful update for more than two weeks, and the issue has a significant impact on using Codex comfortably on Windows, especially on lower-spec machines.

I sincerely hope the team can provide an update or improvement soon.

If possible, could you please let us know whether this issue is currently being worked on, or whether there is a target Desktop/MSIX build containing a fix?

Thank you very much for your hard work and for continuing to improve Codex.

ChatGPT v26.825.32147 includes a fix for one cause of Windows stuttering and slowdowns during long sessions. Sandboxed commands could cause Desktop Window Manager (dwm.exe) resources to accumulate. The fix reuses private Windows desktops for commands with the same permissions.

Please update to ChatGPT v26.825.32147 or later, restart the app, and let us know whether this helps.

If the problem continues after updating, please share your version and steps to reproduce.

Thank you for your reports and investigation!

@chess-oai

@chess-oai 👍🎉
Oh, it looks like it’s fixed now! I just updated to the latest version on my mini PC. It has been stable immediately after the update, and it’s also working reliably after completely quitting and restarting ChatGPT.

Thank you so much. I’m really excited to get back to developing with Codex again. If I run into any more issues while using it, I’ll be sure to report them. You can consider me a mini PC tester!

Thank you again! 😊

After some minutes...

[Windows][Desktop 26.707.12708.0] ChatGPT.exe spawns hundreds of taskkill.exe/conhost.exe processes, causing WMI storms and DWM degradation #33776

Description

[Windows][Desktop 26.707.12708.0] ChatGPT.exe spawns hundreds of taskkill.exe and conhost.exe processes, causing WMI failure storms and DWM degradation

Summary

Environment

User-visible symptoms

Process-tree evidence

DWM and Codex resource growth

WMI failure storm

Codex renderer and Windows event evidence

Steps to reproduce

Expected behavior

Working diagnosis

Current workaround

Related reports

Privacy note

Activity

github-actions commented on Jul 17, 2026

mweichse commented on Jul 18, 2026

BIOcanse commented on Jul 18, 2026

Source-level root cause and the 26.707 -> 26.715 regression boundary

1. Git cancellation invokes an unbounded process-tree kill

2. The live review query creates and cancels per-file Git subprocesses

3. PID-only /T cleanup becomes a self-sustaining cross-kill loop

4. Full-machine CIM sampling amplifies the loop into an OS freeze

5. The process registry is not crash-safe

Local version boundary

Required remediation

Release and ownership concern

BIOcanse commented on Jul 18, 2026

Exact regression boundary: build 5484, Git review metadata worker

Reproducible four-build comparison

What changed in build 5484

Exact current shipped files (build 5538)

Requested maintainer action

cnxobo commented on Jul 18, 2026

Additional clean-reboot reproduction on 26.715.3651.0

Environment

Clean-reboot reproduction

Desktop log evidence

Northern-Summer commented on Jul 18, 2026

BIOcanse commented on Jul 18, 2026

Correction: exact direct-parent boundary, two independent defects, and maintainer source anchors

Defect A: the producer continuously creates cleanup work

Defect B: PID-only /T cleanup does not converge

Maintainer source-search anchors

Fresh reproduction separating the two defects

Separate but related release-quality failure: large-conversation UI loading

tsukimori-dev commented on Jul 18, 2026

Controlled A/B isolation: the Desktop child-process snapshot sampler triggers the WMI CPU storm

Environment

Confirmed observations before the intervention

Controlled intervention and result

Important limitation

Requested upstream changes

Claim boundary

BIOcanse commented on Jul 18, 2026

Temporary mitigation for affected Windows users: Codex Process Guard

ZoerZhu commented on Jul 20, 2026

Diagnostic update: the Git child-process timeout precedes the taskkill / WMI storm

Revised working diagnosis

Requested fix / instrumentation

13 remaining items

bbingz commented on Jul 26, 2026

Analysis (community)

Important boundary

Root-cause hypothesis

lilvli commented on Jul 30, 2026

meza commented on Aug 1, 2026

henkosch commented on Aug 1, 2026

Independent occurrence with DWM handle accumulation and Windows UI degradation

User-visible impact

Environment

System responsiveness at inspection

DWM measurements

Application memory

WMI evidence

Display and event-log checks

Mitigation attempts

Force-closing VS Code

[Windows][Desktop 26.707.12708.0] `ChatGPT.exe` spawns hundreds of `taskkill.exe` and `conhost.exe` processes, causing WMI failure storms and DWM degradation

Defect B: PID-only `/T` cleanup does not converge

Diagnostic update: the Git child-process timeout precedes the `taskkill` / WMI storm

Current-main source follow-up: hook cleanup still has an unreaped `taskkill` fallback