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

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

• #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:

1. 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.
2. Reuse a persistent worker/console rather than starting a fresh PowerShell, console host, and sandbox refresh for every command.
3. Have workspace tracking apply Git ignore/exclusion rules before hashing and batch paths through hash-object (for example, using --stdin-paths).
4. 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:

~~~js
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:

~~~text
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:

~~~powershell
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 6ad0e943cc72 (#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

1. 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.
2. Replace taskkill /T with a Windows Job Object or bounded Toolhelp traversal. Bind cleanup to PID plus creation time/process handle, not PID alone.
3. Add a hard timeout, concurrency limit, deduplication, and single-flight semantics to cleanup. Never await a cleanup helper indefinitely.
4. Coalesce working-tree invalidations and batch Git paths. Do not spawn one Git process per untracked file.
5. Replace full-machine WMI polling with Job Object accounting, Toolhelp, ETW, or direct process handles scoped to owned children.
6. Write the process registry atomically with temp-file + flush + rename, validate it on load, and recover from a last-known-good copy.
7. 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

1. Fully reboot Windows.
2. Launch Codex Desktop.
3. Open one local thread and run read-only shell diagnostics. Some WMI/CIM-based commands timed out.
4. 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:

1. Replace per-sample PowerShell/WMI spawning with a persistent or native helper.
2. Coalesce sampling and add rate limiting/backoff/circuit breaking.
3. Correctly reap taskkill/conhost cleanup children and stop retry amplification.
4. 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:

1. 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.
2. 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: https://github.com/JimLiu/decode-codex/compare/54c373f781d0ee51f0c16f58ec349ae97a16f941...fa0ef1d8be41adc202d1f92e80cf1937f59ae45a

• 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:

• #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.
• #25390 reproduces a nearly frozen Desktop UI with a 242.5 MB / 50,589-line local thread.
• #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.
• #29590 shows eager resume/hydration stalls at much smaller history sizes.
• #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:

1. rapid Git invalidation/cancellation with assertions on process births, cleanup convergence, PID identity, handles, threads, and WMI activity;
2. 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 openai/codex#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

1. Add a supported emergency switch to disable child-process snapshot sampling on Windows.
2. Replace repeated PowerShell/WMI full-machine polling with a persistent native helper, Toolhelp/process handles, or Windows Job Objects scoped to Codex-owned descendants.
3. On timeout, cancel and await the underlying WMI work rather than only terminating the client process.
4. Enforce single-flight/backpressure, a hard concurrency cap, deduplication, and exponential backoff.
5. Bound the PID set and avoid giant OR filters against Win32_Process.
6. 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:

1. The Desktop UI itself becomes visible in roughly 2–3 seconds.
2. The background sidebar_workspace_task_groups_task_dirs / Git-origin discovery work starts.
3. Git commands launched through the Desktop process environment hang until a fixed 60,000 ms timeout.
4. 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.
5. After the timeout, Desktop invokes:

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

1. 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.

I implemented and isolated-tested a bounded cleanup change in the public Rust process paths, but I want to keep the claim narrower than the full Desktop/WMI report here.

Public comparison:

https://github.com/openai/codex/compare/main...luziyi123448-gif:codex/loop-death-fix?expand=1

The Windows portion of the branch:

• assigns exec-server process trees to a Windows Job Object with KILL_ON_JOB_CLOSE;
• closes the Job to reap surviving descendants;
• keeps the legacy taskkill fallback no-window, bounded to two seconds, and single-flight;
• trips a process-wide creation breaker on Windows error 164 so cleanup cannot amplify thread/resource exhaustion;
• applies the same Job Object cleanup primitive to the rmcp-client stdio launcher.

The task-owned Windows regression starts a short-lived parent/child helper tree, verifies neither helper has a console window, closes the Job, waits for both exact process handles to exit, and asserts that the task-owned taskkill attempt counter did not increase. The error-164 injection test verifies that later process creation is suppressed after the breaker trips. Both tests pass on the rebased branch; the full codex-rmcp-client package also passes 109/109 tests.

Scope boundary: this does not modify or claim to fix the closed-source Desktop child-process snapshot worker, its PowerShell/WMI sampler, or every ChatGPT.exe cleanup producer discussed in this issue. It addresses the public exec-server/rmcp process-tree and fallback amplification paths. The compare also contains the separately reported completed-thread lifecycle fix from #33957; it can be split if maintainers invite a focused contribution.

Additional Windows Codex Desktop diagnostics

Feedback/session ID: 019f7a60-2f25-7de2-be94-44b7ddb83f2b

Environment: Windows, Codex Desktop package 26.715.4045.0 (ChatGPT.exe file version 150.0.7871.124).

I reproduced the issue on Windows Codex Desktop by opening Codex and a project chat without entering a prompt or starting a task.

Confirmed correlated activity chain

ChatGPT.exe / codex.exe
-> repeated git.exe
-> repeated taskkill.exe
-> repeated Win32_Process WMI queries
-> sustained WmiPrvSE.exe CPU load

Across the completed ETW, WMI, and Process Monitor diagnostics, the measured values were:

• Average WmiPrvSE.exe CPU: 18.6346%
• Maximum WmiPrvSE.exe CPU: 35.7490%
• Dominant repeated Git command: git.exe config --null --get core.fsmonitor
• Dominant-command executions: 81
• Average dominant-command interval: approximately 0.7267 seconds
• Child git.exe processes: 171
• Unique taskkill.exe PIDs: 153

The filtered Process Monitor data also showed repeated status, ls-files, diff, hash-object, rev-parse, and merge-base operations. The saved Process Monitor event timestamps span 58.257 seconds, although the intended manual capture duration was 30 seconds; intervals above were calculated from the observed timestamps.

Verdict and limitation

PARTIAL_CAUSE_CONFIRMED

The repeating Git operation and the tight temporal correlation with repeated taskkill.exe activity are confirmed. However, the selected Process Monitor filter did not retain the command-line arguments or target PID of taskkill.exe, so it does not yet prove that taskkill.exe was terminating those specific Git PIDs. The exact internal Codex component responsible for initiating the outer process chain is also not captured by this dataset.

Rejected hypotheses

The following were tested and rejected as necessary causes:

• Git-Based Review mode
• chat_processes.json
• stale saved terminal states as a necessary cause

Most likely direction

The strongest remaining direction is a repository watcher or overlapping repository-state checks that lack single-flight protection or rate limiting. A per-repository single-flight guard would prevent a new Git state-refresh batch from starting while the previous batch is still active.

Related issue: #34005, which reports repeated git config --null --get core.fsmonitor activity.

Privacy and local artifacts

The raw PML is intentionally not being published because it may contain sensitive local metadata.

The following sanitized files exist locally but are not attached to this comment:

• PROCMon-GIT-TASKKILL-REPORT.md
• procmon-git-taskkill-safe.csv

Confirmation: same review-summary → git abort → taskkill storm on Windows Desktop 26.715.7063.0

This matches the chain described in #30820 / #33776 / #32113 / #27570. Local evidence below (no prompt content, no secrets).

Environment

• OS: Windows 11, PowerShell
• Codex Desktop package: OpenAI.Codex 26.715.7063.0 (OpenAI.Codex_2p2nqsd0c76g0)
• Previously also reproduced on 26.715.4045.0; in-app update did not fix
• Git itself is healthy in the affected repos (git status ~50–65 ms, no merge/rebase/index.lock, fsck --connectivity-only OK)

Symptom

1. Open Codex Desktop → CPU rises quickly; Task Manager freezes/lags when refreshing process list
2. Fully quit Desktop (window + tray) → process storm stops immediately
3. Even when opening a clean worktree via codex://threads/new?path=..., background work still targets a previously saved local project in the sidebar

15s process sample (during active storm, post-update)

PID-diffing style sampler (unique short-lived PIDs over 15s):

| Metric | Value |
| --- | --- |
| Unique taskkill.exe | 262 (~17.5/s) |
| Unique git.exe | 226 (~15.1/s) |
| ChatGPT CPU seconds (15s window) | 5.88 |
| ChatGPT processes | 8 |

Baseline with Desktop fully exited: UniqueTaskkill=0, no ChatGPT/CodexMicroService.

Desktop log signature (exact fields)

Log root:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\

Repeated pattern:

requestKind=review-summary
source=review_model
failureReason=aborted
failureReason=abortedBeforeStart
failureReason=spawnFailed
failureReason=waitFailed
errorMessage="Git snapshot became stale"

Aborted Git subcommands observed:

• git hash-object
• git diff --no-index (per untracked file, e.g. scratch/*.py)
• git diff --cached
• git status
• git diff against HEAD for a small set of tracked changes

Trigger cwd in current session (redacted base):

cwd=D:/AI/<local-project-A>

Also previously observed on a second local monorepo under the same parent folder.

Representative command shapes (same as other reports):

git -c core.hooksPath=NUL -c core.fsmonitor= hash-object -- <path>
git ... diff --no-index --raw --numstat -z -- /dev/null scratch/<file>.py
git ... diff --cached <HEAD> --no-renames --name-only -z

Also saw sidebar PR chip work against the same cwd:

requestKind=gh-pr-status
source=sidebar_task_pr_chip
cwd=D:/AI/<local-project-A>

Two-day log aggregation (local)

From recent non-empty Desktop logs:

• review-summary-related Git complete lines: 4476
• Early-cancel lines without cwd: 3706 (all failed/aborted)
• One dirty monorepo cwd: 742 lines (710 failed/aborted)
• Another dirty project cwd: 28 lines (all failed/aborted)
• Git snapshot became stale: 55

Important negative findings (not root cause)

• Not a merge/rebase conflict, index.lock, or corrupt object DB
• Not continuous on-disk mutation: 10s mtime/size compare of dirty paths showed 0 changing files while snapshot still went stale
• Not slow Git: git status ~65 ms in the hottest project
• Defender / WMI / Task Manager behave as amplifiers/victims, not the primary producer (matches #33776 control experiment: kill ChatGPT → storm collapses)
• Linked clean worktree for another project briefly looked healthy, then logs showed the storm was still scanning <local-project-A> restored from sidebar / local projects — clean worktree alone is not a durable fix

Global state / project registry shape

.codex-global-state.json contained multiple local-projects entries and a selected-project pointing at the dirty project. Desktop restored/scanned that project even when the user deep-linked into a different clean path. This aligns with #32113 (saved/inactive projects still scanned) and #30820 (startup restore → eager review-summary).

Workspace shape that amplifies (not required for the bug, but makes it severe)

Hot project approximately:

• ~7 tracked modifications/deletions
• large untracked tree under scratch/ (order of ~90+ files) plus other untracked dirs
• .gitignore did not cover scratch/diagnostics dumps
• No nested-repo fanout proven in this capture (unlike #27570), but untracked-per-file hash-object / diff --no-index is enough to feed the cancel/taskkill loop on Windows

A/B already tried (local)

| Attempt | Result |
| --- | --- |
| App update 26.715.4045 → 26.715.7063 | Still reproduces |
| Clean linked worktree deep-link | Current project quiet; other saved project still storms |
| Precise .git/info/exclude | Did not stop loop |
| git add -N intent-to-add | Did not stop; reverted |
| Fully exit Desktop | Storm stops immediately |

Request

Please treat this as another independent Windows confirmation on 26.715.7063.0 of:

1. Eager/live review-summary / review_model over restored or saved local projects
2. Per-file untracked Git fanout + abort
3. taskkill /T /F cleanup feedback loop freezing process enumeration / Task Manager

Happy to validate a patched Desktop build quickly. Can also provide sanitized log excerpts on request.

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.