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.