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

[jrf1001]

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

26.527.31326

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop repeatedly spawns short-lived powershell.exe children under the Codex.exe GUI process to run full-machine CIM/WMI scans over Win32_Process and Win32_PerfFormattedData_PerfProc_Process.

In a fresh 30.05s measurement, I observed 23 PowerShell/pwsh processes, approximately 0.77/sec, consuming about 48.95 CPU-seconds total. Roughly 1.6 logical cores of sustained load from this recent change to how Codex monitors apps.

Confirmed child command examples:
powershell.exe -NoProfile -NonInteractive -Command "... Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId | ConvertTo-Json -Depth 2"

powershell.exe -NoProfile -NonInteractive -Command "... Get-CimInstance Win32_PerfFormattedData_PerfProc_Process ... Get-CimInstance Win32_Process ... CommandLine,WorkingSetSize,..."

What steps can reproduce the bug?

019e7fe2-7262-7c50-bbbc-0a374d0db752

1. Run Codex Desktop on Windows.
2. Watch child processes under Codex.exe using Task Manager, System Informer, or Get-CimInstance Win32_Process.
3. When active, Codex.exe repeatedly spawns powershell.exe children running Get-CimInstance Win32_Process / Win32_PerfFormattedData_PerfProc_Process.

I do not yet have a deterministic trigger; the loop appears intermittent or state-dependent but happens while conversations are ongoing.

What is the expected behavior?

Codex Desktop should not spawn PowerShell repeatedly for full-machine process polling. Process tracking should be throttled, non-overlapping, scoped to Codex-owned process trees, or implemented through a persistent/native helper.

Additional information

This appears to be Codex Desktop app behavior, not the standalone Codex CLI. The parent process is the packaged Windows app Codex.exe, and the likely source is Desktop process-manager code in app.asar.

This did not happen before the updates at the end of last week (~28th/29th).

[github-actions]

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

• Windows desktop regression: long "thinking" hangs, reconnect behavior, failed child process snapshot, and turn-state desync after update #24748

Powered by Codex Action

[jrf1001]

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"

[grnbtqdbyx-create]

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

[grnbtqdbyx-create]

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

[privacyguy123]

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.

[houyupeng]

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.

[XucroYuri]

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

[CIVDX]

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.