[Windows Desktop] Full-process PowerShell/WMI polling remains in 26.721.4979.0 and contributes to system-wide input lag #36176

What version of the Codex App are you using (From “About Codex” dialog)?

26.721.41059

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

Codex Desktop on Windows can cause intermittent mouse and keyboard stalls across the entire operating system, not only inside the app.

The strongest confirmed contributor is repeated full-machine process discovery launched by the Desktop app through short-lived PowerShell processes and WMI/CIM queries.

The current Store package tested here, OpenAI.Codex 26.721.4979.0, still contains and executes these process-inventory paths.

A 30-second stock capture recorded five Desktop-descendant WMI-inventory PowerShell starts, seven total PowerShell starts, 79 conhost.exe starts, and 172 captured descendant starts.

A narrowly patched copy of the same current runtime recorded zero WMI-inventory PowerShell starts in two separate 30-second runs. It retained the same 13 live runtime processes and remained alive in both runs.

An earlier controlled A/B on package 26.707.3351.0 isolated the command-registry discovery path. Suppressing that path reduced:

• WMI PowerShell starts from 26 to 0 per minute;
• paired WMI conhost.exe starts from 26 to 0;
• maximum low-level mouse-event delivery delay from 234 ms to 16 ms;
• events delayed over 100 ms from 1 to 0.

That is direct intervention evidence that Desktop-generated process discovery materially contributes to the system-wide stalls.

Automatic repository-origin discovery is a second process-amplification path. In a matched A/B on 26.707.3351.0, suppressing it reduced git.exe starts from 206 to 22 in about 47 seconds.

The current local mitigation is an unsupported diagnostic patch, not a production-ready fix. It disables optional discovery features in a copied runtime while leaving the signed Microsoft Store package untouched.

This issue consolidates the root cause, current patch, measurements, and related public reports into one tracker.

The earlier reports are linked below rather than restated as separate claims. This report adds current-build reproduction, the 26.721.4979.0 patch port, fresh validation, and one cross-issue technical map not present in a single existing issue.

Affected environment

Independent reports show the same query families across older and newer releases. Examples range from 26.506.3741.0 in #22912 through the 26.715 reports listed below.

User-visible impact

• Mouse movement and typing intermittently stall across unrelated Windows applications.
• The problem is often most visible during launch, command execution, project refresh, or task switching.
• Local captures show PowerShell, console-host, WMI, and Git activity. Related public reports also correlate some events with Defender or cleanup-process spikes.
• Some reports observe continued background activity after the app window closes, until the remaining Desktop process tree is terminated.
• The symptom is not limited to renderer frame rate. A low-level Windows hook measured delayed event delivery before downstream application rendering.

Actual behavior

Several independent Desktop paths can request overlapping global process snapshots. Each snapshot creates process-launch, console-host, WMI-provider, serialization, and teardown work.

Other paths can concurrently fan out Git commands or repeatedly attempt process cleanup. Together, these can create sustained machine-wide contention and visible input stalls.

What steps can reproduce the bug?

The exact trigger is state-dependent, but the underlying process-inventory work is directly observable.

1. Launch the Windows Desktop app.
2. Open a project and use a task that executes local commands.
3. Observe the full ChatGPT.exe descendant tree with Process Monitor, Process Explorer, System Informer, ETW, or a native Toolhelp-based ancestry monitor.
4. Record process command lines and WMI Provider Host activity.
5. Watch for short-lived powershell.exe, conhost.exe, git.exe, and taskkill.exe children or descendants.
6. Check whether mouse or keyboard delivery stalls in another foreground application at the same time.

The two characteristic WMI query families are:

Get-CimInstance Win32_Process |
  Select-Object ProcessId, ParentProcessId |
  ConvertTo-Json -Depth 2

and:

$cpuByPid = @{}
Get-CimInstance Win32_PerfFormattedData_PerfProc_Process |
  ForEach-Object {
    $cpuByPid[[int]$_.IDProcess] = [double]$_.PercentProcessorTime
  }
Get-CimInstance Win32_Process

The second command also collects process details such as command line and working-set size.

What is the expected behavior?

Routine Desktop operation should not repeatedly launch PowerShell to enumerate every process on the machine.

Process tracking should be scoped to app-owned children, coalesced, cached, bounded, and implemented without degrading input delivery in unrelated applications.

Repository metadata work should be proportional to unique repository roots, not the number of submitted working directories or UI refreshes.

Additional information

Technical root cause

The packaged Electron application contains several separate process-discovery consumers. They do not share one cached, single-flight snapshot.

1. Telemetry/process-snapshot worker

The bundled worker is:

.vite/build/child-process-snapshot-worker.js

The current call path is:

30-second focused heartbeat, renderer-ready event, or renderer snapshot request
  -> Electron sampler collectSnapshotFields()
  -> addChildProcessFields()
  -> child-process-snapshot-worker.js
  -> Win32_Process parent scan
  -> Win32_PerfFormattedData_PerfProc_Process
     plus Win32_Process detail scan

The current main bundle has a 30-second heartbeat and a 5-second minimum gate for non-heartbeat triggers.

On Windows, the worker launches fresh PowerShell processes for both WMI query families.

PID detail work is chunked, so one snapshot can involve one parent scan and one or more detail scans.

2. Shared process-subtree discovery

The current shared bundle is:

.vite/build/src-BPbHdvxe.js

In package 26.721.4979.0, the module-exported seam is:

export Tn
  -> internal IW
  -> full Win32_Process parent scan
  -> filtered descendant resolution
  -> performance/process-detail WMI scan

This implementation is separate from the telemetry worker and can independently execute the same global inventory work.

3. Chat-process registry private dependencies

The current registry class captures the original implementations in a private dependency object:

$Y = {
  listDetachedProcessCandidates: LW,
  listProcessSubtrees: IW
}

Its mutation path is:

registry upsert() / complete()
  -> resolve a missing osPid
  -> retry at approximately 0, 100, 300, and 600 ms
  -> privately captured listProcessSubtrees()
  -> detached-process fallback if still unmatched
  -> PowerShell/WMI

Each subtree attempt can execute two PowerShell/WMI inventory commands. The final detached fallback can execute another.

Source inspection therefore permits up to nine PowerShell/WMI inventory invocations for one unmatched mutation. A command may invoke the mutation at both start and completion.

Replacing only the exported process-snapshot function does not affect these privately captured references.

This registry path produced the strongest controlled process and input-delivery A/B.

4. Chrome native-host cleanup

The current release contains another process-inventory consumer:

export gn
  -> internal BK
  -> default Windows listProcesses()
  -> detached-process inventory
  -> WMI

Its confirmation loop uses delays of approximately 0, 100, 200, 400, and 800 ms.

Internal callers can retain the original dependency rather than looking up the public export. An export-only override is therefore insufficient for the current build.

This is another global process-inventory and cleanup consumer.

The broader taskkill.exe/conhost.exe reports may reflect a related lifecycle defect, but this trace does not establish that BK/gn launches taskkill.exe. The verified cleanup here uses process.kill.

5. Automatic Git-origin discovery

The Git worker accepts lists of directories and resolves them concurrently:

git-origins worker request
  -> normalize and deduplicate submitted directories
  -> Promise.all(directory resolutions)
  -> repository metadata and origin lookup

Representative commands include:

git rev-parse --show-toplevel
git rev-parse --git-common-dir
git config --get remote.origin.url
git config --null --get core.fsmonitor

Multiple UI directory sets, malformed or empty .git directories, and cache invalidation can recreate the fan-out.

This is a separate contributor to process churn. It should not be conflated with the command-registry WMI path that produced the direct input-latency A/B.

Why an app-local defect affects the whole system

The local captures directly demonstrate operating-system-wide work rather than only renderer work:

• repeated PowerShell and console-host creation and teardown;
• global WMI process and performance inventory;
• concurrent Git and console-host creation;
• process-tree construction and JSON serialization;
• delayed low-level input-hook delivery.

The linked reports separately document WMI quota exhaustion, Defender load, taskkill storms, DWM degradation, and kernel-resource pressure.

Those reports show the breadth of the Windows process-lifecycle problem. They are not all locally reproduced mechanisms in the current experiment.

The historical input probe measured delay at the low-level Windows hook callback. That places the observed stall before any affected foreground application renders the input.

Current diagnostic patch

The patch is applied to a copied runtime. The signed Store installation remains untouched.

Current build-specific mapping

The minified identifiers changed between releases. For 26.721.4979.0, the exact ordinal, case-sensitive mappings are:

These identifiers must be rediscovered for every build.

There are important case hazards in this release:

• lowercase kn exports xW, a browser/Chrome configuration object;
• lowercase rn exports wY, an instruction-builder function;
• uppercase Gn is unrelated to lowercase gn.

Reusing the older build's mappings, or comparing names case-insensitively, can silently patch unrelated functionality.

Packaging procedure

1. Leave the signed Store package untouched.
2. Copy the entire matching Store app directory into a separate versioned runtime.
3. Archive and extract resources/app.asar.
4. Preserve the original JavaScript files beside or outside the extracted source.
5. Install three wrapper files implementing the six mitigation behaviors below.
6. Repack the ASAR with the matching native-module layout.
7. Overlay the new app.asar and app.asar.unpacked into the copied runtime.
8. Verify that all non-ASAR executables and resources still match the same Store release.
9. Do not run the Store runtime and copied runtime simultaneously because they share application state.

The repack command used for the current build was:

npx.cmd --yes '@electron/asar@4.2.0' pack <source> <output> `
  --unpack-dir '{node_modules/better-sqlite3,node_modules/node-pty}' `
  --unpack '**/*.node'

The matching app.asar.unpacked directory must remain beside the ASAR.

Do not combine a new ASAR with an older executable or runtime. Electron, native-module ABI, Codex binaries, and packaged resources may all change between releases.

Patch 1: return an empty optional telemetry snapshot

Replace the telemetry child-process worker while preserving its successful response contract:

parentPort.postMessage({ type: "ok", value: [] });

This prevents that worker from launching either PowerShell/WMI query family.

Patch 2: intercept only automatic git-origins

Preserve the original Git worker as worker-original.js.

Install a wrapper at the expected worker.js path before loading the original. Intercept only messages satisfying all three conditions:

workerData.workerId === "git"
message.type === "worker-request"
message.request.method === "git-origins"

Return a successful result containing:

{ origins: [] }

The response must retain the original request identifier and worker protocol. Delegate every other request and event to worker-original.js.

Patch 3: suppress the exported shared process snapshot

Preserve the current shared module as:

.vite/build/src-original-BPbHdvxe.js

Leave a wrapper at the original src-BPbHdvxe.js path.

On Windows, replace only export Tn with:

const emptyProcessSnapshot = async () => [];

Pass every unrelated export through unchanged.

Patch 4: stop registry mutations from scanning

On Windows, replace export en with a subclass of the original registry.

Inherited reads remain available. Only the two mutation methods that trigger private process discovery become no-ops:

class NonScanningChatProcessRegistry extends original.en {
  async upsert() {}
  async complete() {}
}

This intentionally reduces command-lifecycle registry persistence.

Patch 5: inject an empty process list into native-host cleanup

Wrap export gn and call the original implementation with its normal options plus a replacement nested dependency:

original.gn({
  ...options,
  dependencies: {
    ...options?.dependencies,
    listProcesses: async () => [],
  },
});

All other cleanup checks remain in the original function.

This prevents this exported cleanup path from performing a global process inventory.

Patch 6: cover private module closures during initialization

Exports alone do not cover private references captured while the original shared module initializes.

Temporarily wrap child_process.execFile only while importing src-original-BPbHdvxe.js.

The interception predicate requires all of the following:

executable basename is powershell.exe
command contains Get-CimInstance
command contains Win32_Process
  or Win32_PerfFormattedData_PerfProc_Process

Matching commands receive JSON []. Unrelated child-process calls delegate to the original execFile.

The wrapper must implement the correct util.promisify.custom behavior because the preserved module uses a promisified form.

Restore the global child_process.execFile in a finally block immediately after module initialization.

The preserved module captures the promisified wrapper during initialization. Its private helpers therefore retain the narrow filter for later calls after the global execFile has been restored.

The effective shared-module behavior is:

Tn -> async () => []
en -> non-scanning registry subclass
gn -> original cleanup with listProcesses: async () => []
unrelated exports -> original implementation
private WMI helpers captured during original-module initialization
  -> matching calls made later return JSON []
unrelated execFile calls -> original implementation

Validation

Original causal A/B: package 26.707.3351.0

The registry comparison used identical diagnostic settings for all other patched paths. The only changed variable was whether registry mutations retained WMI discovery.

One-minute process-ancestry comparison

Low-level input-delivery comparison

The probe compared each event timestamp with the time its WH_MOUSE_LL or WH_KEYBOARD_LL callback ran. It measured delivery to the hook, not renderer latency.

Matched Git-origin comparison

The launch windows were approximately 47 seconds. A separate ancestry capture confirmed that the large Git burst descended from Desktop.

Current patch port: package 26.721.4979.0

Two patched 30-second process-ancestry runs were compared with a stock 30-second run:

After each probe, the harness closed the main window, force-stopped any remaining copied-runtime processes, and verified that zero remained.

The current stock window did not happen to contain an automatic Git-origin probe. Current Git coverage therefore combines a worker contract test with the earlier matched process A/B.

The three current captures were separate launch windows without a matched active-command workload.

Total descendant and conhost.exe counts are descriptive, not precise performance deltas. The deterministic pass criteria were zero classified WMI inventories and zero automatic origin probes, backed by contract tests.

The current tests prove that the identified WMI and automatic-origin hot paths were absent during the measured windows. They do not prove that every source of Desktop lag or every cleanup loop is fixed.

Patch verification gates

The current build passed:

• JavaScript syntax checks for wrappers and preserved originals;
• exact telemetry-worker response-contract checks;
• git-origins interception and non-origin delegation tests;
• behavior checks for Tn, en, and gn;
• restoration checks for global child_process.execFile;
• guards proving kn, rn, and Gn remain identical to their original unrelated exports;
• packed-ASAR extraction comparisons;
• native-module layout checks;
• comparisons of ten critical executable, Codex, Electron, and rg.exe resources against the matching Store payload.

Only the intended app.asar and matching app.asar.unpacked overlay differed from the copied Store runtime.

At final verification, the live Store ASAR still matched the archived source ASAR. The Store installation was not modified.

Limitations and functional tradeoffs

• All consumers of the telemetry worker snapshot or Tn receive no descendants. This includes Desktop child-process observation and its process-list/kill UI.
• Registry insertion/update and completion/removal through upsert() and complete() are disabled.
• Automatic repository-origin discovery returns no origins. Repository grouping and project metadata may therefore be less accurate.
• Chrome native-host cleanup cannot discover candidate processes through global inventory. Stale native-host or extension-host candidates may not be terminated through that path.
• The patch does not prove that every taskkill.exe cleanup path is disabled.
• Ordinary Git operations, non-git-origins worker traffic, and unrelated PowerShell or child-process calls remain enabled.
• The copied runtime does not receive Store updates and must be rebuilt for each release.
• The minified bundle names and exports are build-specific and must never be carried forward without source inspection.

Evidentiary limits

• The current build refresh includes direct process-creation validation but no new low-level input-latency A/B.
• The 234 ms to 16 ms result is a controlled single-run comparison on the earlier affected build, not a long-duration benchmark.
• The current stock capture contained no automatic origin probes, so the current run is not a fresh Git process-count A/B.
• The Toolhelp ancestry monitor sampled every 25 ms. It can miss very short-lived processes.
• Command-line classification can miss a process that exits before its command line is read. The reported counts are lower bounds.
• The low-level hook probe measured delivery to its callback, not downstream app rendering.
• Elevated ETW was not used to isolate the final Windows kernel contention point.
• Not every PowerShell, Git, console-host, or cleanup process is necessarily unnecessary.

The causal conclusion is based on source tracing, process ancestry, a narrow intervention, and symptom-boundary input measurements.

Recommended upstream fix

The affected features can be preserved without routine global PowerShell/WMI scans.

1. Track app-owned processes at the shared spawn boundary.
2. Route all process-discovery consumers through one replaceable dependency.
3. If enumeration is unavoidable, use one native snapshot, cache it briefly, coalesce concurrent requests, and cancel superseded work.
4. Do not retry optional process telemetry when discovery is unavailable.
5. Make PID resolution bounded and event-driven instead of performing several global scans at command start and completion.
6. Separate process observation from cleanup. Cleanup should act only on explicitly owned PIDs with start-time or process-handle validation.
7. Canonicalize and deduplicate repository paths before origin lookup.
8. Cache origin data per repository root, use bounded concurrency, and cancel stale requests.
9. Ignore malformed or empty .git markers rather than repeatedly probing them.
10. Keep process inventory behind one testable interface so private closures cannot bypass throttling or caching.

Suggested Windows regression budgets

• Zero routine Desktop-descendant PowerShell commands containing Win32_Process or Win32_PerfFormattedData_PerfProc_Process.
• Process starts proportional to unique repository roots, not submitted directory count.
• At most one in-flight process snapshot for all consumers.
• No unbounded taskkill.exe or conhost.exe loops.
• No measurable low-level mouse or keyboard delivery regression during active command traffic.
• Bounded process cleanup after app exit.

Requested outcome

Please use this issue as a canonical tracker for the Windows process-inventory and process-fan-out defect family.

The requested product outcomes are:

• replace routine PowerShell/WMI process inventory with bounded, app-owned process tracking;
• coalesce and cache any unavoidable native snapshots;
• make process cleanup ownership-aware and bounded;
• bound and cache repository-origin discovery;
• add Windows process-creation and low-level input regression tests;
• provide a supported feature flag or temporary mitigation until the upstream implementation ships.

I can provide sanitized command-line captures, ancestry data, wrapper-contract tests, and additional measurements if maintainers need them.

Related public reports

The index below was checked against GitHub on 2026-07-28.

It includes the original report, every issue linked from that report, the existing discussion, direct WMI/Git/cleanup reports found in a fresh search, and a separate group of similar symptoms.

The categories matter. The first four groups contain direct mechanism or close process-lifecycle evidence. The final groups are included for context and are not presented as proof of the same cause.

Primary history

Direct WMI and process-snapshot evidence

Cleanup-loop and taskkill.exe/conhost.exe evidence

These reports establish a close process-lifecycle failure family. The local patch covers known snapshot, registry, origin, and native-host inventory paths, but this issue does not claim it disables every cleanup path.

Git-origin, repository-discovery, and kernel-pressure evidence

Similar Windows symptoms without confirmed shared cause

Logging and SQLite pressure referenced by the original report

These can cause severe Desktop slowdowns but are not evidence for the WMI/Git mechanism.

Non-Windows reports linked by the original issue

The original issue also referenced these as broad performance comparisons. They are not part of the Windows WMI/Git causal cluster.

• #20547 — Desktop sluggishness after an update — Open
• #21326 — macOS renderer CPU and UI lag — Closed

Technical references

• Original public root-cause and patch writeup
• OpenAI: ChatGPT for Windows
• Microsoft: Win32_Process
• Microsoft: low-level mouse hook event data
• Microsoft: low-level keyboard hook event data
• Microsoft: taking a process snapshot with Toolhelp
• Electron: application distribution
• Electron: ASAR archives