Windows Codex Desktop spawns powershell.exe every second for full process polling, causing high CPU usage

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

• #24748

Powered by Codex Action

I used Codex to help try investigate, and it found an anomaly:

~\.codex\process_manager\chat_processes.json had 15 stale entries for conversations that happened the day prior.

After clearing the stale entries and restarting Codex, the expensive checks still happen but at a slower interval than before.

Each launch of the powershell still is doing these commands that take ~1 or 2 seconds of ~2 CPU cores to complete.

``powershell.exe -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId | ConvertTo-Json -Depth 2"``

``powershell.exe -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; $cpuByPid = @{}; Get-CimInstance Win32_PerfFormattedData_PerfProc_Process | ForEach-Object { $cpuByPid[[int]$_.IDProcess] = [double]$_.PercentProcessorTime }; Get-CimInstance Win32_Process -Filter \"ProcessId = 4392 OR ProcessId = 6368 OR ProcessId = 7132 OR ProcessId = 7160 OR ProcessId = 9384 OR ProcessId = 9528 OR ProcessId = 10408 OR ProcessId = 10868 OR ProcessId = 10876 OR ProcessId = 12048 OR ProcessId = 13772 OR ProcessId = 13872 OR ProcessId = 14400 OR ProcessId = 14828 OR ProcessId = 15604 OR ProcessId = 15652 OR ProcessId = 15932 OR ProcessId = 16024 OR ProcessId = 17308 OR ProcessId = 18164 OR ProcessId = 19972 OR ProcessId = 20632 OR ProcessId = 24368 OR ProcessId = 25228 OR ProcessId = 25320 OR ProcessId = 25328 OR ProcessId = 25404 OR ProcessId = 25916 OR ProcessId = 27828 OR ProcessId = 27832 OR ProcessId = 28396 OR ProcessId = 28788 OR ProcessId = 29300 OR ProcessId = 30292 OR ProcessId = 31736 OR ProcessId = 32152 OR ProcessId = 33536 OR ProcessId = 33948 OR ProcessId = 33988 OR ProcessId = 34356 OR ProcessId = 34544 OR ProcessId = 35192 OR ProcessId = 35244 OR ProcessId = 35364 OR ProcessId = 35852 OR ProcessId = 36868 OR ProcessId = 37092 OR ProcessId = 37712 OR ProcessId = 38156 OR ProcessId = 38520 OR ProcessId = 38608 OR ProcessId = 38724 OR ProcessId = 39336 OR ProcessId = 40392 OR ProcessId = 40492 OR ProcessId = 40580 OR ProcessId = 40840 OR ProcessId = 41416 OR ProcessId = 42652 OR ProcessId = 43232\" | Select-Object ProcessId,ParentProcessId,CommandLine,WorkingSetSize,@{Name='CpuPercent';Expression={$cpuByPid[[int]$_.ProcessId]}},@{Name='AgeSeconds';Expression={[int]((Get-Date) - $_.CreationDate).TotalSeconds}} | ConvertTo-Json -Depth 2"``

`` powershell.exe -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; $cpuByPid = @{}; Get-CimInstance Win32_PerfFormattedData_PerfProc_Process | ForEach-Object { $cpuByPid[[int]$_.IDProcess] = [double]$_.PercentProcessorTime }; Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId,CommandLine,WorkingSetSize,@{Name='CpuPercent';Expression={$cpuByPid[[int]$_.ProcessId]}},@{Name='AgeSeconds';Expression={[int]((Get-Date) - $_.CreationDate).TotalSeconds}} | ConvertTo-Json -Depth 2"``

I added a small helper for packaging this kind of evidence without posting raw full-machine process dumps: trace-to-skill@0.1.73 now has process-audit.

npx trace-to-skill@0.1.73 process-audit ./process-notes.md --output process-audit.md

Scope note: it does not inspect live processes or mutate Codex state. It parses process notes/snippets that a user already captured from Task Manager, System Informer, Get-CimInstance, ps, top, etc. It currently flags:

• PowerShell/pwsh CIM polling such as Get-CimInstance Win32_Process / Win32_PerfFormattedData_PerfProc_Process
• high-CPU Codex/helper/renderer samples
• stale process_manager/chat_processes.json mentions
• runaway helper signals

The output includes a checklist for sample duration, child process count, approximate spawn rate, CPU-seconds, parent Codex.exe PID, and redacted command lines. Release/proof: https://github.com/grnbtqdbyx-create/trace-to-skill/releases/tag/v0.1.73

I added a small local report helper for this kind of evidence in trace-to-skill@0.1.73:

npx trace-to-skill@0.1.73 process-audit ./process-notes.md --output process-audit.md

Scope note: it does not inspect live processes or modify Codex state. It only turns pasted/saved process evidence into a smaller public report, so users do not need to attach raw full-machine process dumps.

It detects:

• powershell.exe / pwsh CIM polling commands such as Get-CimInstance Win32_Process and Win32_PerfFormattedData_PerfProc_Process
• sample summaries with child process count, approximate spawn rate, and CPU-seconds
• stale process_manager/chat_processes.json mentions
• high-CPU Codex/helper/renderer samples

Release/proof: https://github.com/grnbtqdbyx-create/trace-to-skill/releases/tag/v0.1.73

Additional confirmation on the latest Windows Desktop build.

Environment

• OS: Windows 10 Pro 10.0.19045, x64
• Codex Desktop package path: C:\Program Files\WindowsApps\OpenAI.Codex_26.623.9142.0_x64__2p2nqsd0c76g0\app\Codex.exe
• Extracted app bundle metadata from app.asar:
• package version: 26.623.70822
• codexBuildNumber: 4559
• Electron: 42.1.0
• Bundled app-server observed:
• C:\Program Files\WindowsApps\OpenAI.Codex_26.623.9142.0_x64__2p2nqsd0c76g0\app\resources\codex.exe app-server --analytics-default-enabled

Observed behavior

Process Explorer showed repeated short-lived powershell.exe children spawned directly by the Electron Codex.exe process. The command line matches the background process telemetry/polling command:

powershell.exe -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; $cpuByPid = @{}; Get-CimInstance Win32_PerfFormattedData_PerfProc_Process | ForEach-Object { $cpuByPid[[int]$_.IDProcess] = [double]$_.PercentProcessorTime }; Get-CimInstance Win32_Process -Filter "ProcessId = ..." | Select-Object ProcessId,ParentProcessId,CommandLine,WorkingSetSize,@{Name='CpuPercent';Expression={$cpuByPid[[int]$_.ProcessId]}},@{Name='AgeSeconds';Expression={[int]((Get-Date) - $_.CreationDate).TotalSeconds}} | ConvertTo-Json -Depth 2"

A short live sample saw fresh process-metadata PowerShell processes under Codex.exe every ~0.5-1s while a Codex turn/tool flow was active. Example sample rows:

Sample  PID    ParentPID  ParentName  Kind
0       25080  18588      Codex.exe   process-metadata
1       10164  18588      Codex.exe   process-metadata
3       17704  18588      Codex.exe   process-metadata
5       26408  18588      Codex.exe   process-metadata
7       19076  18588      Codex.exe   process-metadata

This was not caused by a user hook or script. The only configured hook command on this machine was a startup-only SessionStart cleanup hook with powershell -NoProfile -ExecutionPolicy Bypass -File ...; the repeated processes were instead powershell.exe -NoProfile -NonInteractive -Command ... Get-CimInstance ... and were parented by Codex.exe.

Installed bundle evidence

Extracting the installed app.asar shows this is coming from the Electron process sampler path.

main-Btzug9bx.js creates a worker named child-process-snapshot:

new Worker(join(__dirname, `child-process-snapshot-worker.js`), {
  name: `child-process-snapshot`,
  workerData: e
})

The same bundled file labels this area electron-sampler, and addChildProcessFields calls the worker on Windows:

process.platform === `win32` ? FQ(process.pid) : ...

The bundled sampler manager has:

var OZ = 3e4, kZ = 5e3, AZ = 6e4

and uses setInterval(() => this.requestAppStateSnapshot('heartbeat'), OZ), so the background heartbeat appears intended to be 30s, with non-heartbeat snapshot triggers gated at 5s. The observed rate can be much higher while the app is active, likely due to additional snapshot triggers and/or overlapping slow WMI/CIM probes.

child-process-snapshot-worker.js launches two Windows PowerShell probes for each snapshot:

powershell.exe -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId | ConvertTo-Json -Depth 2"

and then:

powershell.exe -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; $cpuByPid = @{}; Get-CimInstance Win32_PerfFormattedData_PerfProc_Process ... Get-CimInstance Win32_Process -Filter ... | Select-Object ProcessId,ParentProcessId,CommandLine,WorkingSetSize,... | ConvertTo-Json -Depth 2"

The worker receives only a root PID via workerData, builds the descendant process set, and then asks PowerShell/WMI for details. The second query still enumerates Win32_PerfFormattedData_PerfProc_Process globally to build $cpuByPid.

Why this remains a problem

Even if the telemetry is intentional, spawning full Windows PowerShell repeatedly for process telemetry is expensive and highly visible in diagnostic tools. On Windows 10 in particular, the combination of powershell.exe startup + Get-CimInstance + global Win32_PerfFormattedData_PerfProc_Process polling is a poor background implementation.

Expected behavior:

• process telemetry should not spawn a fresh PowerShell process per snapshot;
• probes should be non-overlapping and rate-limited;
• telemetry should stop or heavily throttle when the app is idle/backgrounded;
• process enumeration should be scoped to the Codex process tree before collecting expensive metrics;
• ideally this should use a persistent/native helper or direct Windows process APIs instead of repeated PowerShell/CIM invocations.

This issue is still present on OpenAI.Codex_26.623.9142.0 / bundle 4559.

EDIT: do you test this code in prod only? Tragic.

Seeing the same pattern on Windows 11 with Codex Desktop.

Local PowerShell event logs show short-lived powershell.exe ConsoleHost sessions around 2026-07-06 17:30:00-17:30:02 and 2026-07-06 22:20:04-22:20:12, running:

Get-CimInstance Win32_Process and Win32_PerfFormattedData_PerfProc_Process, then ConvertTo-Json.

A live sample showed the powershell.exe process parented by Codex.exe. User-visible impact includes black console flashes and intermittent mouse/keyboard stutter. This also matches #26613.

Confirmed on a newer Windows Desktop build with the same global WMI sampling command.

Environment

• Codex Desktop: 26.707.3748.0
• Codex CLI: 0.144.1
• OS: Windows 11 Pro for Workstations, build 26200, x64
• CPU: Intel Core i5-9400F, 6 cores / 6 logical processors

Captured process

A live process-tree snapshot found a short-lived powershell.exe directly parented by the packaged Desktop ChatGPT.exe. Its command line contained the same sequence described in this issue:

powershell.exe -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; $cpuByPid = @{}; Get-CimInstance Win32_PerfFormattedData_PerfProc_Process | ForEach-Object { ... }; Get-CimInstance Win32_Process -Filter \"ProcessId = ...\" | Select-Object ProcessId,ParentProcessId,CommandLine,WorkingSetSize,@{Name='CpuPercent';Expression={...}},@{Name='AgeSeconds';Expression={...}} | ConvertTo-Json -Depth 2"

The filter listed a large set of Desktop, app-server, MCP, Node, renderer, and command-runner PIDs, while Win32_PerfFormattedData_PerfProc_Process was still enumerated globally to build the CPU map.

I also captured the separate Git-process churn on this machine. GPU utilization remained only 1-3%, so repeated Windows process creation and global WMI queries are a much better fit for the observed fan activity than GPU saturation.

An unprivileged Win32_ProcessStartTrace subscription was denied by WMI on this machine, so I am not claiming an exact PowerShell spawn rate from this run. The captured parent PID and command line do confirm that the expensive sampler path is still present in 26.707.3748.0.

Suggested fix

Use a persistent/native process sampler, scope expensive metrics to the already-discovered descendant PIDs, make snapshots single-flight, and coalesce active-turn triggers so they cannot overlap the heartbeat sampler.

---
This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated

Additional confirmation from a newer Windows Desktop build, with ETW/WMI attribution and user-visible impact.

Environment

• Codex Desktop package: 26.707.12708.0
• OS: Windows 11 x64
• CPU: Intel Core i9-14900K (32 logical processors)

Evidence

The machine exhibits sustained total CPU usage in the roughly 30-60% range during the affected state, with about eight logical-processor graphs remaining continuously busy and severe system-wide input/UI stutter.

An ETW trace of Microsoft-Windows-WMI-Activity correlated the activity with short-lived PowerShell clients spawned by the packaged Codex Desktop process (ChatGPT.exe). The queries were handled by two WMI Provider Host instances:

• WmiPerfInst servicing Win32_PerfFormattedData_PerfProc_Process
• CIMWin32 servicing Win32_Process

This matches the commands and Electron sampler path already documented in this issue. The installed 26.707.12708.0 bundle still contains the same Get-CimInstance Win32_Process and Get-CimInstance Win32_PerfFormattedData_PerfProc_Process polling implementation.

The symptom is particularly misleading in Task Manager/Resource Monitor: individual WmiPrvSE.exe rows can show low sampled averages while total CPU usage is much higher, but the high total CPU state consistently coincides with the polling activity and real machine stutter.

Impact

This is not merely a cosmetic telemetry issue. Repeated full-machine process polling:

• wastes CPU time and electrical energy while Codex is open;
• increases heat and cooling/fan activity;
• reduces responsiveness even on a high-end desktop CPU;
• materially disrupts normal work and makes it impractical to leave Codex Desktop running.

Please prioritize a fix or provide an immediate supported kill switch. At minimum, the sampler should be single-flight, aggressively rate-limited/coalesced, idle-aware, and restricted to the Codex-owned process tree. A persistent/native Windows process sampler would avoid repeatedly launching PowerShell and globally enumerating WMI performance classes.

This comment was prepared and submitted by OpenAI Codex using the affected user's GitHub account with the user's explicit permission.

Confirmed this still reproduces on the current Microsoft Store build 26.715.4045.0 on Windows 11 (20 logical processors), including while the Codex desktop app is visibly idle.

A/B confirmation

• With Codex Desktop open and idle, WmiPrvSE.exe remains active.
• Fully closing Codex Desktop immediately returns WMI Provider Host CPU to normal.
• Reopening Codex reproduces the load without starting an agent task.

Live measurements

Using Windows Process performance counters, the busy WmiPrvSE.exe instance averaged 8.42% of total machine CPU over 10 seconds and peaked at 10.10%. A second sample averaged 6.62% and peaked at 21.69% of total machine CPU.

Provider troubleshooting counters identified CIMWin32 in that host as the active provider:

CIMWin32 ExecQueryAsync: +93 calls in 5 seconds (18.6/sec)
CIMWin32 CreateInstanceEnumAsync: +2 calls in 5 seconds

A six-second Msft_WmiProvider_ExecQueryAsyncEvent_Pre capture observed 120 queries. The dominant query occurred 86 times (about 14.3/sec):

select __RELPATH, __PATH, ProcessId, CSName, Caption, SessionId,
       ThreadCount, WorkingSetSize, KernelModeTime, UserModeTime,
       ParentProcessId
from Win32_Process

There were also repeated per-PID ExecutablePath / CommandLine queries and large ProcessId = ... OR ProcessId = ... filters.

Since boot, the WMI Operational log contained 893 Event 5858 client failures:

579 x 0x80041032 (WBEM_E_CALL_CANCELLED)
185 x 0x800706BA (Could not send status to client)

The reported client PIDs belonged to short-lived processes and had exited by inspection time.

Installed bundle correlation

The current packaged app.asar still contains Windows process snapshot code that launches hidden powershell.exe and runs both:

Get-CimInstance Win32_PerfFormattedData_PerfProc_Process
Get-CimInstance Win32_Process

It also constructs the same Get-CimInstance Win32_Process -Filter "ProcessId = ... OR ProcessId = ..." query shape recorded by WMI. The renderer contains a child-processes query configured with intervalMs: 5000, but the measured rate is much higher than one snapshot every five seconds, suggesting duplicated/overlapping callers or another unbounded refresh path.

No WMI service crashes, WmiPrvSE quota events, or signature anomalies were found. This appears to be application-driven polling rather than WMI corruption.

Current workaround: fully exit Codex Desktop when it is not actively needed. Restarting or rebuilding WMI is not an appropriate workaround.

Potential duplicates/related reports: #29499 and #33875.

Independent confirmation on the current Microsoft Store build, with a live process count and installed-package correlation.

Environment

• Codex Desktop MSIX: OpenAI.Codex_26.715.4045.0_x64
• OS: Windows 11 x64
• WSL was not involved

Live impact and attribution

During the affected state:

• WmiPrvSE.exe reached 36.24% of total-machine CPU while total CPU was 83.97%.
• The busy provider host was serving CIMWin32.
• Over the preceding 10 minutes, Codex Desktop created 140 unique short-lived PowerShell processes:
• 67 process-tree snapshots
• 73 process-detail/performance snapshots
• In one burst, 13 separate WMI clients issued the same broad Win32_Process query and failed in the same millisecond with RPC error 0x800706BE.
• PowerShell engine logs contained the exact Get-CimInstance commands embedded in the installed Codex package, and the processes were direct children of the packaged Desktop ChatGPT.exe.

Installed-package confirmation

Read-only inspection of the installed app.asar shows:

• the sampler manager schedules a focused heartbeat every 30 seconds;
• non-heartbeat triggers are admitted every 5 seconds, including delta_burst, thread_started, turn_started, and turn_completed;
• the Windows snapshot worker launches PowerShell for:
• Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId
• Get-CimInstance Win32_PerfFormattedData_PerfProc_Process
• filtered Get-CimInstance Win32_Process detail queries;
• child-process enrichment runs unconditionally in snapshot collection;
• the rate gate only checks snapshot start timestamps: there is no in-flight/single-flight guard, coalescing, or WMI failure backoff. When WMI becomes slow, new snapshots can overlap and amplify the load;
• disabling analytics does not disable this Windows process sampler.

This matches the observed burst of simultaneous clients and explains why a nominal 5/30-second schedule can become a WMI storm.

Requested fix

Please provide an immediate supported kill switch for Windows host/process sampling, then make collection single-flight, coalesced, timeout-bounded, and protected by exponential backoff/circuit breaking. A persistent native collector scoped to the Codex process tree would avoid repeatedly launching PowerShell and globally enumerating WMI classes.

No prompts, conversation contents, usernames, local paths, or raw private logs are included. This comment was prepared and submitted by Codex using the affected user's GitHub account with the user's explicit permission.

Additional reproducible evidence for this issue follows. This narrows the failure to overlapping WMI snapshot paths and a fixed 5-second timeout, including retriggering on window focus.

Exit code: 0
Wall time: 20.7 seconds
Output:

[Windows Desktop] Repeated PowerShell/WMI process snapshots hit a fixed 5-second timeout on startup and window focus

Summary

Codex Desktop for Windows launches overlapping PowerShell/WMI process-enumeration commands from at least two internal paths. Both enumerate system-wide process data, and one path uses a fixed 5-second timeout.

On a Windows system where these valid WMI queries take roughly 4.3–4.7 seconds when warm and more than 5 seconds when cold, the commands repeatedly time out or fail. The same work is triggered again when the Codex window receives focus. This causes repeated WMI provider activity and noticeable CPU usage.

This appears to be an application bug rather than a damaged WMI repository or a permanent permissions problem: the exact queries succeed under the same user account when allowed to finish.

Environment

• Product: Codex Desktop for Windows
• Package version: OpenAI.Codex_26.715.3651.0_x64__2p2nqsd0c76g0
• Executable: C:\Program Files\WindowsApps\OpenAI.Codex_26.715.3651.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe
• OS: Windows 11 x64
• Date observed: 2026-07-19

Actual behavior

Two independent call paths launch PowerShell and query WMI/CIM:

1. ChatGPT.exe -> electron-sampler -> child-process-snapshot-worker.js -> powershell.exe -> Get-CimInstance
2. ChatGPT.exe -> BundledPluginsMarketplace plugin reconciliation / stop_chrome_native_host -> powershell.exe -> Get-CimInstance

The queried classes include:

• Win32_Process
• Win32_PerfFormattedData_PerfProc_Process

Inspection of the installed application package shows the sampler creates child-process-snapshot-worker.js, invokes powershell.exe -NoProfile -NonInteractive, and applies a fixed timeout = 5e3 (5,000 ms). The process is hidden and the output buffer is set to 8 MiB.

The application log shows the sampler and plugin reconciliation failing close together. The pattern repeats after window focus:

• electron-sampler failure while querying Win32_Process
• BundledPluginsMarketplace failure while querying Win32_PerfFormattedData_PerfProc_Process and Win32_Process
• bundled_plugins_reconcile_started reason=focus
• another sampler failure
• another plugin WMI failure

WMI Activity logs at the same timestamps show provider activity for CIMWin32, WmiPerfClass, and WmiPerfInst. Subsequent WMIBinaryMofResource activity under SYSTEM appears to be downstream provider initialization, not a separate direct Codex query.

Timing evidence

The queries were measured outside the Codex sandbox, under the same Windows user account.

Individual queries, three runs each:

| Query | Run 1 | Run 2 | Run 3 |
|---|---:|---:|---:|
| Win32_Process | 1,899 ms | 1,713 ms | 2,642 ms |
| Win32_PerfFormattedData_PerfProc_Process | 4,675 ms | 2,689 ms | 2,602 ms |

The combined Codex-equivalent command completed successfully in:

• 4,670 ms
• 4,269 ms
• 4,446 ms

This leaves only 330 ms of margin against the fixed 5,000 ms timeout in the slowest warm run. In an earlier cold run, the performance-class query took 5,931 ms, and the combined command took approximately 6.3 seconds.

Therefore, normal timing variation is sufficient to cross the application's timeout. Starting two overlapping full-system WMI enumerations can make the condition more likely and increases CPU load even when both eventually succeed.

Steps to reproduce

1. Start Codex Desktop on Windows.
2. Monitor child processes, the Codex application log, and Microsoft-Windows-WMI-Activity/Operational.
3. Observe hidden powershell.exe children running Get-CimInstance for Win32_Process and/or Win32_PerfFormattedData_PerfProc_Process.
4. Switch away from Codex and focus the Codex window again.
5. Observe bundled_plugins_reconcile_started reason=focus, followed by another set of WMI calls and, on affected machines, timeout/failure warnings.

The issue is easier to reproduce during cold WMI provider startup or other system load.

Expected behavior

• Codex should not repeatedly launch overlapping system-wide WMI process snapshots on startup or every focus event.
• A valid query that takes slightly more than 5 seconds should not be treated as a persistent failure and immediately retried through another subsystem.
• Process sampling should have bounded CPU cost and should expose enough diagnostics to distinguish timeout, cancellation, non-zero exit, and WMI/application errors.

Suggested fixes

1. Share one single-flight process snapshot between electron-sampler and bundled-plugin reconciliation instead of launching duplicate WMI work.
2. Increase the timeout to at least 10 seconds, or make it configurable.
3. Cache/debounce snapshots across startup and focus events.
4. Query only the Codex descendant process tree instead of enumerating all system processes.
5. Prefer native Windows process APIs over PowerShell/WMI for parent/child process discovery.
6. Log whether the command timed out, was killed/cancelled, exited non-zero, or returned WMI/protocol errors.
7. Provide a supported setting to disable the sampler as a mitigation.

Configuration note

Changing the Codex workspace sandbox setting is not expected to fix this issue. The WMI calls originate from the desktop host application and also reproduce as normal same-user commands outside the sandbox. No supported setting was found for changing the sampler timeout or disabling these WMI snapshots.

Available diagnostics

• Redacted Codex Desktop log excerpts with matching timestamps
• WMI Activity event timestamps and provider names
• CSV containing the per-query timing measurements
• Exact redacted PowerShell command shape and exit/timing results

Before uploading any full log or session transcript, it should be reviewed for local paths, prompts, repository names, environment variables, tokens, and other sensitive information.

Local evidence references (not public paths)

• App log: %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\07\19\...log
• Timing CSV: codex_diagnostics\current-wmi-latency-20260719.csv

Confirming and extending this report with ~3h of diagnostic data collected tonight.

Environment: Codex Desktop 26.715.4045.0 (current), Windows 11 Pro build 26200, 12 logical cores. The bug is still fully present in this version.

1. Spawn cadence and query shapes. The spawner is the app's main process (ChatGPT.exe with no --type= flag). It launches powershell.exe -NoProfile -NonInteractive roughly every 1–2 s — I captured 11 spawns in a 20 s window. Three rotating query shapes:

• Full Get-CimInstance Win32_PerfFormattedData_PerfProc_Process scan, then a Win32_Process query whose filter is a machine-generated list of ~120 literal ProcessId = N OR … clauses (the watched-PID list changes every round);
• full parent/child map: Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId | ConvertTo-Json;
• full process scan including per-PID CPU, CommandLine, WorkingSetSize, AgeSeconds.

The watched PIDs are the app's own processes, codex.exe, the cua_node runtime, MCP servers, and terminals of running agent tasks (e.g. an npm run package:smoke the agent had started).

2. Where the cost lands (why Task Manager never blames Codex). Measured attribution on a fully loaded machine: Codex-named processes ≈ 3% of total CPU; induced load ≈ 48% — WmiPrvSE.exe up to ~2.5 cores servicing the full-machine scans, MsMpEng.exe (Defender) scanning every short-lived spawn, svchost (Winmgmt) and DWM handling conhost churn. Total ≈ 51% of a 12-core machine attributable to this loop. Quitting the app instantly dropped total CPU from ~100% to ~30%.

3. External mitigation is a losing arms race. A watchdog killing the spawned pollers at birth (250 ms cadence) made the app retry faster — spawn rate roughly doubled to ~2/s (>2,300 spawns in ~20 min). Suspending the main process does stop the loop but hangs system-wide UI (window-message broadcasts block on the frozen queue — same symptom family as #31236), so that's not viable either.

4. Partial relief that worked: a Defender process exclusion for powershell.exe cut MsMpEng from ~0.6 to ~0.15 cores. Also, session accumulation matters: after ~12 h the app had 9 × ChatGPT.exe, 6 × codex.exe and 53 orphaned conhost.exe alive.

Suggested fix direction: replace the spawn-a-fresh-PowerShell-per-tick design with one persistent native/helper worker doing incremental, scoped polling of Codex-owned process trees (as the OP suggested). That would eliminate essentially all of the WMI + Defender + process-churn cost described above.

Still reproducible on Codex Desktop 26.715.7063.0 (Microsoft Store package, Windows x64).

I independently traced the high-CPU event on an affected machine:

• WmiPrvSE.exe reached 55.9% total CPU.
• The repeated client process chain was powershell.exe <- ChatGPT.exe, where ChatGPT.exe is the signed packaged OpenAI Codex desktop host.
• The PowerShell children repeatedly executed Get-CimInstance Win32_Process and Get-CimInstance Win32_PerfFormattedData_PerfProc_Process.
• Microsoft-Windows-WMI-Activity/Operational recorded repeated failures including 0x80041032 and 0x800706BA.

Inspection of the installed app.asar matches the implementation described above: child-process-snapshot-worker.js launches a full Win32_Process query, then a second query that globally enumerates Win32_PerfFormattedData_PerfProc_Process before fetching details for descendant PIDs. The sampler has a 30-second heartbeat and a 5-second minimum interval for non-heartbeat triggers; streamed deltas can trigger delta_burst snapshots. I did not find an in-flight/single-flight guard around snapshot creation.

A sampled WMI phase took about 3 seconds, so overlapping snapshots are a plausible amplifier when another trigger arrives before the previous two-phase snapshot completes. This overlap is an inference from the bundled code and timings, not yet proven with internal instrumentation.

Suggested fix directions:

1. Make Windows snapshots single-flight and coalesce pending triggers.
2. Avoid a global Win32_PerfFormattedData_PerfProc_Process enumeration for every delta burst.
3. Scope collection to the Codex descendant tree and cache process-tree data.
4. Prefer native Windows process APIs over spawning PowerShell/WMI for each sample.

No user paths, workspace names, hostnames, or conversation content are included here.

Opening any conversation starts sustained WMI CPU usage.
Switching to another conversation does not stop it.
Opening Settings immediately stops WMI activity.

WMI Event ID 5858:
Win32_PerfFormattedData_PerfProc_Process
ResultCode = 0x800706BA
PossibleCause = Could not send status to client

Additional PowerShell 5.1 vs PowerShell 7 A/B Evidence

Additional confirmation with a controlled Windows PowerShell 5.1 vs PowerShell 7 A/B test.

Environment

• Codex Desktop: 26.721.3404.0
• Platform: Windows x64
• Windows PowerShell: 5.1
• PowerShell: 7.6.3
• Power plan: Balanced
• AC minimum processor state: 80% throughout all tests

I confirmed that the Codex Desktop main process (ChatGPT.exe) launches powershell.exe to execute the same two WMI/CIM queries reported in this issue:

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

and:

Get-CimInstance Win32_PerfFormattedData_PerfProc_Process
Get-CimInstance Win32_Process

Inspection of the installed application bundle showed that this process-monitoring path invokes powershell.exe explicitly. On a standard Windows installation, that resolves to Windows PowerShell 5.1 even when PowerShell 7 is installed.

Exact-query A/B Results

The same queries were executed separately with Windows PowerShell 5.1 and PowerShell 7.6.3.

| Query | Runtime | Wall time | Aggregate CPU time |
|---|---|---:|---:|
| Process tree | PowerShell 5.1 | 1335 ms | 2631 ms |
| Process tree | PowerShell 7.6.3 | 473 ms | 531 ms |
| Process statistics | PowerShell 5.1 | 1774 ms | 2656 ms |
| Process statistics | PowerShell 7.6.3 | 795 ms | 587 ms |

For these queries, PowerShell 7 reduced aggregate CPU time by approximately 78-80%.

All queries completed successfully and returned compatible JSON data in both runtimes.

Codex Desktop End-to-End Test

As a local diagnostic workaround, I launched Codex Desktop with a process-local PATH entry containing a native powershell.exe forwarding shim. The shim forwards the original arguments, standard streams, working directory, and exit code to:

C:\Program Files\PowerShell\7\pwsh.exe

I verified the actual live process chain:

ChatGPT.exe
  -> powershell.exe (process-local forwarding shim)
     -> pwsh.exe 7.6.3

No files under System32, no permanent user or machine PATH values, and no Codex application package files were modified.

Using the same 60-second monitoring workload:

| Metric | Original PS 5.1 path | PS 7 forwarding path |
|---|---:|---:|
| Average CPU temperature | 70.6 C | 40.3 C |
| Maximum CPU temperature | 80.1 C | 59.5 C |
| Average CPU package power | 22.0 W | 7.1 W |
| Maximum CPU package power | 38.1 W | 22.7 W |
| Average CPU load | 17.5% | 2.8% |
| Maximum CPU load | 39.9% | 17.8% |

The thermal starting conditions were different between the two 60-second runs, so the exact-query timings, aggregate CPU time, package power, and CPU load are the stronger evidence.

The processor power settings were not reduced between tests. In particular, the AC minimum processor state remained at 80%.

Conclusion

Repeated full-machine WMI polling and overlapping snapshot triggers remain the underlying design problem. However, explicitly invoking Windows PowerShell 5.1 substantially amplifies its CPU, power, and thermal cost.

A relatively low-risk immediate mitigation would be:

1. Prefer pwsh.exe when PowerShell 7 is installed.
2. Fall back to Windows PowerShell 5.1 only when PowerShell 7 is unavailable.
3. Alternatively, make the PowerShell executable configurable.

The longer-term fix should still make process snapshots single-flight and coalesced, avoid repeated global Win32_PerfFormattedData_PerfProc_Process enumeration, and preferably use a persistent helper or native Windows process APIs.

Codex app is simply unusable on windows due to extreme cpu usage - its been more than a two weeks with no fix.

Confirmed on current Windows Codex Desktop

I can reproduce this on Windows 11 with:

• Codex Desktop MSIX: OpenAI.Codex_26.721.4979.0
• Desktop host: packaged ChatGPT.exe

After a full Windows reboot and a full Codex restart, Codex repeatedly creates short-lived powershell.exe and conhost.exe children at roughly once per second.

The conhost.exe windows visibly flash on screen, which is extremely disruptive during normal work.

What I captured

The repeated processes are direct descendants of the packaged Codex Desktop main process. They are not caused by Task Scheduler, my backup job, a custom hook, Chrome, or an external PowerShell script.

The PowerShell children repeatedly run full-machine CIM/WMI inventory commands including:

Get-CimInstance Win32_Process
Get-CimInstance Win32_PerfFormattedData_PerfProc_Process

The returned data includes:

• ProcessId
• ParentProcessId
• CommandLine
• WorkingSetSize
• CPU percentage
• process age

The results are serialized to JSON and returned to the desktop app.

Impact

This is not merely cosmetic:

• Repeated visible console flashes interrupt normal work.
• Codex creates a steady stream of short-lived PowerShell and console-host processes.
• The activity creates continuous WMI/process-monitoring load.
• It is concerning that Codex repeatedly enumerates command-line data from running processes without a visible explanation or supported control.
• Restarting Codex does not resolve it; the polling begins again.

Request for an OpenAI response

There are now multiple reports across Windows versions and Codex Desktop builds spanning at least two months.

Can an OpenAI maintainer please:

1. Confirm whether this sampler is intentional and identify the owning component.
2. Provide a supported setting or kill switch to disable Windows process sampling.
3. Provide an immediate workaround that stops the visible console flashes and WMI polling without modifying the installed app package or weakening Windows security.
4. Clarify whether the collected process/command-line data is stored locally, transmitted, or used only transiently for local process tracking.
5. Confirm whether a fix is planned to make these snapshots single-flight, coalesced, idle-aware, and scoped to Codex-owned processes.

I can provide a sanitized process-tree capture and redacted command lines if that would help reproduce or triage this.

Reproduced on Windows 11 with OpenAI.Codex 26.721.11231.0. In a 15-second trace, the main ChatGPT.exe process spawned five PowerShell WMI scans using Win32_Process / Win32_PerfFormattedData_PerfProc_Process and five conhost.exe processes. System-wide UI/input stuttering occurs despite normal-looking aggregate utilization. In-app feedback/session ID: 019faed9-2563-7e20-971e-e266e59b5717.

Confirming this is still reproducible on Codex Desktop 26.721.4979.0 on Windows 11 x64 build 26200.

The packaged Desktop app—currently hosted by ChatGPT.exe with Codex child processes—continues to spawn short-lived powershell.exe and conhost.exe processes executing the same full-system queries described here:

• Get-CimInstance Win32_Process
• Get-CimInstance Win32_PerfFormattedData_PerfProc_Process

During approximately six minutes of active tool use, I observed roughly 400 PowerShell/conhost process pairs. A separate longer process-start capture attributed 13,131 PowerShell starts and 4,333 Git starts directly to the Desktop host process. Activity increases sharply around tool-command start and completion.

The user-visible result is severe system-wide input and window-animation stuttering even though CPU, memory, storage latency, and processor queue are nowhere near saturation. Fully closing Desktop substantially improves responsiveness. Restarting Windows clears the accumulated degradation temporarily, but it returns after continued Desktop use. Using Codex without the Desktop host running does not reproduce the same behavior.

There may also be persistent security-object churn: during an affected session, lsass.exe reached more than 22,000 handles, dominated by Semaphore and Token handles, compared with only a few thousand following a clean boot. I am not claiming that this proves an LSASS defect, but the growth closely follows active Desktop process creation and survives sleep until reboot.

An empty/malformed .git directory was found to amplify Git/conhost probing, but correcting that does not address the separate WMI process-polling path.

Additional reproduction data from a newer Windows Codex Desktop build.

Environment:

• Windows 11 Pro, 64-bit, version 10.0.26200, build 26200
• Codex Desktop MSIX package: OpenAI.Codex_26.721.11231.0_x64__2p2nqsd0c76g0
• Main desktop process: packaged ChatGPT.exe
• Bundled Chromium observed in process annotations: 150.0.7871.128
• Codex app-server child command:

...\app\resources\codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled

• Host Node/npm also installed: node v24.14.0, npm 11.9.0

User-visible symptoms:

• A visible black console window flashes every few seconds while Codex Desktop is open.
• Normal PC use becomes degraded: typing/rendering stutters and Task Manager shows very high memory pressure.
• A reboot temporarily clears the symptom only until Codex Desktop is opened again.

Observed over several diagnostic windows:

1. Initial real-time process-start tracing showed the visible console was conhost.exe, launched under short-lived PowerShell children owned by Codex Desktop:

explorer.exe -> ChatGPT.exe -> powershell.exe -> conhost.exe

1. In a corrected 15-second Win32_ProcessStartTrace capture, there were 14 powershell.exe launches directly from ChatGPT.exe, and each had a conhost.exe child.

1. The sampled PowerShell command repeatedly queried full-machine process/performance data:

• Get-CimInstance Win32_Process
• Get-CimInstance Win32_PerfFormattedData_PerfProc_Process
• ConvertTo-Json

1. Historical PowerShell/event-log evidence from one affected hour showed 863 matching PowerShell starts.

1. After a clean Windows reboot on 2026-07-31, reopening Codex Desktop reproduced the loop. Before the diagnostic capture started, 53 matching PowerShell starts were already present within about three minutes. A representative post-reboot live chain was:

ChatGPT.exe -> powershell.exe -> conhost.exe

1. During a later affected period, memory pressure was visible at the OS level rather than just inside foreground apps:

• Task Manager showed roughly 90% memory in use.
• Windows memory counters showed active paging under pressure, e.g. available memory around 2.8-2.9 GiB with Pages/sec around 121-180 and Page Reads/sec around 79-93.
• This later relaxed after the process storm subsided; a later snapshot showed available memory around 3.7 GiB and low paging.

1. A separate short-lived node.exe burst was also observed. This was not the persistent small node_repl.exe helper. The parent chain during the burst was:

ChatGPT.exe -> codex.exe -> codex-command-runner-0.146.0-alpha.3.1.exe -> pwsh.exe -> npm.ps1 -> node.exe

A 30-second high-frequency capture around 09:46:59-09:47:03 caught many transient node.exe processes. PowerShellCore event ID 4104 logs confirmed repeated execution of the standard C:\Program Files\nodejs\npm.ps1 wrapper at 09:46:58, 09:47:16, 09:48:10, and 09:50:59 local time. A later 45-second polling window caught no live node.exe, which suggests these processes are very short-lived and bursty.

Working interpretation:

• The PowerShell/visible-console behavior is still reproducible on 26.721.11231.0.
• The visible black window is a conhost.exe child of Codex-owned PowerShell process polling.
• The new node.exe observation appears to be a separate Codex command-runner path invoking host npm through PowerShell (npm.ps1), not the normal persistent node_repl.exe helpers.
• I cannot prove from source whether both behaviors share the same internal trigger, but from live parent chains both are owned by the Codex Desktop process tree.

Expected behavior:

• Codex Desktop should not repeatedly spawn visible console windows for process polling.
• Process polling/cleanup should be throttled, non-overlapping, scoped, and non-visible.
• Short-lived command-runner/npm/node subprocess bursts should not create enough OS-level memory/paging pressure to degrade the Windows desktop.

Privacy note:

• I intentionally omitted the Windows username, workspace names, conversation contents, raw Codex databases, and full private paths. I can provide sanitized traces if maintainers need a narrower artifact.

same here!

Codex Desktop on Windows: WMI/Git/taskkill process storm causes system-wide stutter

Paste-ready issue report

Summary

Codex Desktop 26.721.11231.0 on Windows repeatedly creates short-lived
PowerShell, conhost, Git, and taskkill processes. ETW process ancestry and
read-only inspection of the installed app.asar point to a feedback-heavy
interaction between:

1. Windows child-process discovery implemented through PowerShell and WMI;
2. chat-process PID reconciliation with multiple retries;
3. automatic Git repository/origin/status discovery; and
4. Windows process-tree cleanup implemented through taskkill.exe /t /f.

The result is system-wide input/UI stutter. Closing the visible window is not a
reliable recovery because background Codex processes may remain. Even after all
Codex processes stop, previously accumulated kernel pool/object state may not
be reclaimed promptly; reboot has been the only consistently reliable reset on
this machine.

Environment

• Codex Desktop: 26.721.11231.0
• Package: OpenAI.Codex_26.721.11231.0_x64__2p2nqsd0c76g0
• app.asar SHA-256:

23A8F5D1645247BD942304DC586C44B8CE63C2E3FC408198F815657731070DB5

• Chromium: 150.0.7871.128
• Windows 11 Home, Simplified Chinese, build 26200
• CPU: AMD Ryzen 9 9955HX
• RAM: 64 GB
• GPU: NVIDIA GeForce RTX 5060 Laptop GPU + AMD Radeon 610M
• Displays: 2560×1600 at 165 Hz and 2560×1440 at 143 Hz

Reproduction

1. Start Codex Desktop and use a local Git-backed task.
2. Keep Codex active for a while.
3. Observe intermittent or sustained system-wide input/UI stutter.
4. Capture process starts with ETW/WPR or sample the process table at high

frequency.

1. Observe repeated PowerShell/conhost and Git/taskkill process families whose

ancestor is the Codex Desktop main process.

Local evidence

1. High-frequency process sampling

In a 30-second sample:

• 38 new powershell.exe
• 42 new conhost.exe

The dominant PowerShell parent was the Codex Desktop main ChatGPT.exe
process.

Observed command lines include:

powershell.exe -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId | ConvertTo-Json -Depth 2"

and:

Get-CimInstance Win32_PerfFormattedData_PerfProc_Process
Get-CimInstance Win32_Process

2. ETW process ancestry

In an approximately 33-second effective WPR pool trace:

• 73 git.exe processes in total
• 68 conhost.exe processes in total
• 31 taskkill.exe processes in total
• 31 git.exe processes directly parented by Codex Desktop ChatGPT.exe
• 30 taskkill.exe processes directly parented by Codex Desktop
• 5 PowerShell processes directly parented by Codex Desktop
• 4 Git processes directly parented by the bundled codex.exe app-server

The taskkill.exe commands were:

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

The Git command families included:

• git config --get core.fsmonitor
• git rev-parse
• git remote
• git status --porcelain
• git for-each-ref
• git diff
• git update-ref

3. WMI cost and failed-client evidence

Eight direct timing runs gave:

• Win32_Process: average about 174 ms, maximum about 258 ms
• Win32_PerfFormattedData_PerfProc_Process: average about 471 ms,

maximum about 489 ms

Recycling all WmiPrvSE.exe provider hosts did not improve those timings while
Codex remained active. This rules out a one-off wedged WMI provider as the
primary cause; the expensive full scans are continuously regenerated.

After excluding events created by an intentionally failed diagnostic watcher,
clean WMI Activity event 5858 records included Codex-launched short-lived
clients disappearing before WMI could return results (0x800706BA, “Could not
send status to client”).

4. Installed-code inspection

Read-only string and byte-offset inspection of:

C:\Program Files\WindowsApps\OpenAI.Codex_26.721.11231.0_x64__2p2nqsd0c76g0\app\resources\app.asar

confirmed the following production code paths:

• child-process-snapshot-worker.js
• Get-CimInstance Win32_Process
• Get-CimInstance Win32_PerfFormattedData_PerfProc_Process
• listProcessSubtrees
• listDetachedProcessCandidates
• git-origins
• core.fsmonitor
• taskkill.exe

The Windows process snapshot implementation launches
powershell.exe -NoProfile -NonInteractive. Its detailed snapshot first
enumerates all Win32_PerfFormattedData_PerfProc_Process instances and then
queries Win32_Process.

The chat-process registry attempts OS-PID reconciliation by calling
listProcessSubtrees with retry delays:

0 ms, 100 ms, 300 ms, 600 ms

If no PID is matched after those attempts, it calls
listDetachedProcessCandidates, which performs another Windows process
enumeration.

The Electron performance sampler invokes the child-process snapshot worker.
Its heartbeat interval is 30 seconds, with other trigger events gated at a
minimum interval of 5 seconds while the relevant window is focused.

Git execution uses killProcessTree: true. On Windows, the installed code's
kill implementation invokes:

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

5. Kernel churn

The WPR pool trace recorded heavy allocation/free churn. Security-token-related
tags were present:

• Toke: 11,834 allocations, about 20.6 MB allocated during the trace
• SeAt: 81,274 allocations, about 7.16 MB allocated during the trace
• SeTd: 11,835 allocations, about 1.55 MB allocated during the trace

Most allocations made during the short trace were freed, so this trace alone
does not prove that every byte of the machine's approximately 4 GB combined
paged/nonpaged pool belongs to Codex. It does prove substantial process,
security-token, WMI, and kernel-object churn coincident with the Codex process
storm.

Excluded alternatives

• Free RAM remained about 48 GB; commit was about 14%.
• Disk busy time peaked at only about 8.3% in the general ETW trace.
• DPC and ISR durations remained sub-millisecond; no storage, USB, network, or

display-driver DPC pathology was present.

• No WHEA, disk, display, or resource-exhaustion event explained the stalls.
• Only standard Microsoft filesystem minifilters were loaded.
• Stopping ASUSOptimization for a controlled interval did not change the

stutter; the service was restored immediately afterward.

• Recycling WmiPrvSE.exe while Codex continued generating scans did not

change WMI latency.

• A large Codex window on the 165 Hz high-DPI display independently increases

DWM work. Moving/resizing it lowers DWM use, but that is only a visible-window
amplifier and does not explain the persistent lag after the window is closed.

Root-cause statement

The active stutter is caused by a Codex Desktop for Windows process-management
and repository-discovery regression. Short-lived Git/process activity causes
repeated PowerShell/WMI process-table scans and forced process-tree cleanup
through taskkill. The resulting process creation/destruction, WMI, scheduler,
filesystem, and security-token churn produces system-wide latency.

This conclusion is verified for the active process storm. The exact owner of
every byte of retained kernel pool after the storm stops remains unverified.

Expected behavior

Codex Desktop should not repeatedly enumerate the full Windows process table or
spawn a new PowerShell/conhost process for routine child-process tracking.
Short-lived Git commands should not amplify into repeated WMI scans and
taskkill process trees. Exiting Codex should terminate every Desktop-owned
background process and promptly stop all related churn.

Suggested product fixes

1. Replace PowerShell/WMI full-table polling with event-driven child-process

tracking or a persistent native helper.

1. Deduplicate concurrent process snapshots and cache one snapshot for all PID

reconciliation operations within a bounded interval.

1. Do not enumerate the entire

Win32_PerfFormattedData_PerfProc_Process class when only a small PID set is
requested.

1. Coalesce upsert/complete reconciliation and avoid retrying short-lived

commands that have already exited.

1. Bound and deduplicate Git-origin/status discovery.
2. Avoid unconditional taskkill /t /f for Git commands that have already

exited normally.

1. Add a supported feature flag to disable Windows child-process telemetry and

automatic repository discovery until the native implementation is fixed.

1. Ensure “Quit” results in zero Desktop-owned ChatGPT.exe, bundled

codex.exe, and helper processes.

Workaround

For prevention, keep Codex Desktop fully closed and use Codex CLI or the VS Code
extension. For an already degraded session, completely terminate the Codex
Desktop process tree, verify that no package-owned helper remains, and then
recycle WmiPrvSE.exe provider hosts. A local recovery script is included at:

codex\tools\recover-codex-desktop-no-reboot.ps1

This stops new churn without changing any persistent Windows configuration.
If system-wide lag remains after the process count is zero and WMI providers
have been recycled, there is no supported selective purge for retained kernel
pool/security objects; reboot remains the reliable reset.

Related reports

• https://github.com/openai/codex/issues/25453
• https://github.com/openai/codex/issues/29436
• https://github.com/openai/codex/issues/29499
• https://github.com/openai/codex/issues/30926
• https://github.com/openai/codex/discussions/29949

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

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

thats really cost me a lot to find the problems, maybe a banked reset as a reward? hahahaha

I am reproducing this on the current Microsoft Store Codex Desktop package 26.803.5235.0 x64 on Windows 11.

Symptoms:

• Codex Desktop remains at high CPU even after a task has finished and the UI appears idle.
• If it starts in a low-CPU idle state, simply moving the mouse over/within the app causes CPU to ramp up again.
• The whole computer becomes laggy; this is not limited to the Codex window.
• Restarting Codex does not clear the issue. Opening ChatGPT Classic alongside Codex makes the overall pressure worse, but the high CPU is attributable primarily to the Codex Desktop process tree.
• Task Manager samples showed the Codex group around 35–50% total CPU while “idle,” and around 50% with an active task. The largest consumers were codex.exe app-server and multiple ChatGPT.exe renderer processes; normal Node/MCP helper processes were near 0% CPU.

I disabled several optional MCP servers and bundled browser/computer plugins, which reduced helper-process count but did not solve the Desktop CPU/input-lag problem. The behavior persists after a complete quit/relaunch.

The reproduction pattern—desktop app open, task activity followed by apparent idle, then mouse movement immediately increasing CPU and system-wide lag—looks consistent with the repeated Windows process-inventory / renderer-snapshot behavior described in the related reports. Please confirm whether this path remains present in the 26.803 Store package and whether there is a supported mitigation or a target release for the fix.

No private task contents, account identifiers, paths, or raw logs included.

On Windows 11 Pro, I updated my copy of the desktop app to 26.803.10989.0 and it ran into this issue still. I had to end the desktop app's task in task manager to prevent another system crash trying to use the desktop app.

Still reproducible on the current Microsoft Store package OpenAI.Codex 26.810.6296.0, Windows x64 build 26200.

Observed behavior:

• With Codex Desktop open and no user-initiated task running, the machine becomes noticeably laggy, including general input and application responsiveness.
• Fully quitting Codex immediately restores normal responsiveness.
• Restarting after the latest update did not resolve it.
• A brief local process sample during a lightweight diagnostic found the main ChatGPT.exe process belonging to the OpenAI.Codex package averaging approximately 8.8% of total system CPU, with about 991 MB private memory. The standalone ChatGPT Classic package was identified separately and excluded from that process attribution.

This has been noticeable since early July and remains present in the August 14 build. No raw logs, account identifiers, task contents, or private paths are included here.