[Windows] Codex Desktop leaks high-CPU elevated PowerShell processes after completed shell tool calls

Start by investigating the Windows Desktop shell-tool process lifecycle described in the report, using the sequential shell-call reproduction and PID/CPU snapshots. Compare completed calls with active background terminals and verify that completion, failure, timeout, cancellation, or closing removes only the owned elevated PowerShell process tree without affecting the unrelated idle process.

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

Exact Desktop build not captured before cleanup; current stable Windows Codex Desktop as of 2026-07-21. codex-cli 0.144.6 is also installed, but the issue occurred in Desktop.

What subscription do you have?

Paid individual subscription

What platform is your computer?

Windows 11 x64, native Windows workspace, built-in Administrator account

What issue are you seeing?

Summary

During a long Codex Desktop thread, ordinary local shell tool calls completed and returned output, but elevated powershell.exe wrapper processes remained alive and continuously consumed CPU.

Over about 26 minutes, 26 separate PowerShell processes accumulated. The machine became severely slow even though the product task had already completed.

Observed behavior

• The 26 processes were created sequentially from 22:32:53 through 22:58:51 on 2026-07-21, matching the period in which Codex executed sequential shell tool calls.
• Each process continued consuming roughly 75%-100% of one logical CPU core after its corresponding tool call had returned.
• A bounded 3-second sample showed all 26 PIDs still alive and each adding about 2.2-3.1 CPU seconds.
• Individual accumulated CPU times later ranged from approximately 1,700 to 3,330 seconds.
• Each process used roughly 75-105 MB RAM; aggregate memory was about 2.4 GB, with aggregate CPU usage exceeding 20 logical cores.
• The processes had no visible windows and had highly similar thread/handle/memory profiles.
• The count did not increase during the bounded sample, but every existing leaked process continued accumulating CPU.

Scope checks

• No Electron process was running.
• No project development/acceptance ports were listening.
• No project acceptance lease or owned background workflow was active.
• An unrelated older, idle PowerShell process remained low-CPU and was deliberately not terminated.
• This was not a name-based cleanup or a project-owned process tree.

Recovery

A normal Stop-Process -Id <exact-pid> -Force attempt failed with Access is denied, because the leaked processes were elevated.

After re-validating the exact PID list, an elevated taskkill command targeting only those 26 PIDs (no /IM, no process-name matching, and no /T) exited successfully. Verification showed REMAINING_TARGETS=0, while the unrelated idle PowerShell process remained alive.

No source code, repository logs, or private project files are attached to this public report.

What steps can reproduce the bug?

I am not intentionally stress-reproducing this because the observed instance consumed more than 20 logical CPU cores and made Windows nearly unusable.

The observed sequence was:

1. Open a local Windows Git workspace in Codex Desktop.
2. Use one long thread that performs many sequential, ordinary shell tool calls (file inspection, Git status/diff checks, build/test checks, and bounded render checks).
3. Allow each shell tool call to finish and return output before the next call.
4. After the task completes, inspect powershell.exe processes by PID and creation time.
5. Take two bounded CPU snapshots a few seconds apart.

Actual result: one elevated, no-window, high-CPU PowerShell process appeared to remain from many completed tool calls, eventually accumulating to 26 processes.

This may be intermittent. Silence or a slow command should not be treated as permission to start duplicate workflows when investigating.

What is the expected behavior?

When a shell tool call finishes, its PowerShell wrapper and console resources should exit unless Codex explicitly registers the process as an active background terminal.

Completed shell calls must not leave elevated PowerShell processes busy-looping. Closing, failing, timing out, or cancelling a tool call should clean up only that tool call's owned process tree.

Additional information

Possibly related reports:

• #34050 (repeated PowerShell creation and system-wide freeze after sustained Windows App activity)
• #34264 (an unbounded recursive scan leaves a pwsh -> powershell process chain running)
• #14758 (Windows app process tree / PowerShell and conhost remain after app close)
• #18983 (Windows shell tool execution can hang and leave PowerShell active)
• #17229 (Windows Git/conhost process leakage)

This case adds a narrower observed failure mode: Codex Desktop remained open, individual shell tool calls had already returned, and 26 separate elevated PowerShell processes remained alive while each continued consuming close to one logical CPU core. No high-frequency creation was observed during the bounded sample; the already leaked processes themselves stayed busy.

A third-party CodexProcessGuard was present for a separate taskkill/Git storm issue. At the relevant baseline it reported IsStorm=false, LiveTaskkillCount=0, and RootCount=0. It does not manage general PowerShell child processes, and no taskkill/Git storm was observed before the manual exact-PID cleanup.

I can provide a sanitized PID/start-time/CPU table if maintainers need it, but I am intentionally not publishing private session logs or repository contents.