[Windows App] Repeated PowerShell process creation leads to a system-wide hard freeze after 20–25 minutes

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

• #34025
• #33776
• #33778
• #34001

Powered by Codex Action

I can reproduce a closely related progressive failure on the same
Codex Desktop version, 26.715.4045.0, and Windows 11 build 26200.

One Ultra session initially continues to make progress, with up to
approximately five subagents. While it is active, unrelated Codex
sessions using different models and different tools become delayed
or fail to start. Over time, the Ultra session itself also begins
experiencing tool timeouts.

The failure is Codex-specific: during the same degraded period,
Claude Code continues to operate normally on the same machine and
the same local repository, including PowerShell, cmd.exe, Git Bash,
file operations, and Git commands.

A controlled diagnostic also found:

• external cmd.exe echo: 20.979 ms
• external PowerShell 5.1 -NoProfile: 15.027 s timeout
• Codex-integrated cmd.exe echo: about 10 s, exit 124
• Codex-integrated trivial file read: about 10 s, exit 124
• repeated Get-CimInstance Win32_Process process-monitoring path
• process-monitor timeout: 5 seconds
• repeated PID matching attempts and serialized pending mutations

A reboot temporarily restores normal PowerShell and Codex operation
without clearing chat_processes.json.

This appears related to #34050, #34026, #32714, and #32562, but adds
a cross-session starvation control and a same-repository Claude Code
control showing that the repository, disk, Git, and shell executables
remain operational.

Update — 2026-08-04: Browser / Windows app discovery appears to trigger the PowerShell process storm

I reproduced the same system-wide hard-freeze for a third time, and this incident provides significantly more precise evidence about the trigger.

The new evidence strongly suggests that the failure path is associated with the Codex Browser / Windows application discovery component, rather than with the project code itself or ordinary terminal command execution.

Incident summary

At approximately 2026-08-04 22:49:20 UTC+08:00, Codex was operating a local web application in:

F:\Quant

Immediately before the freeze, the bundled Browser runtime was active and Codex was interacting with a locally hosted page.

Observed PowerShell activity during the incident:

• PowerShell console startup events: 523
• Unique PowerShell PIDs observed: 467
• Peak startup rate: 67 starts per minute
• PowerShell warning events: 137
• The 137 warnings were concentrated between 22:48:37 and 22:48:39
• The abnormal shutdown occurred approximately 41 seconds later
• Active Codex execution contexts at the time: 4

To clarify: 523 does not mean that 523 PowerShell processes existed simultaneously. It means that 523 PowerShell startup events were recorded during approximately 39 minutes, involving 467 distinct PIDs.

Codex task involved

Task ID:

019fcd0d-3241-7ac1-99a1-d934182803c0

Working directory:

F:\Quant

Codex process PID:

36312

Immediately before the system freeze, Codex was performing the following operations:

1. Starting:

npm --workspace apps/web run dev

1. Connecting to:

http://localhost:3000/

1. Initializing the bundled Browser runtime.
2. Taking control of the browser tab.
3. Capturing screenshots.
4. Enumerating browser tabs and Windows applications/processes.

PowerShell script involved

The encoded PowerShell script associated with the warnings was safely decoded.

It performed operations equivalent to:

• Get-StartApps
• Reading Explorer UserAssist registry data
• Get-Process
• Reading executable paths for running processes
• Matching installed applications against running processes
• Serializing the resulting application/process data to JSON

This appears to be Windows application discovery functionality used by the Browser / desktop-control layer.

The incident therefore appears to follow this pattern:

Codex Browser / desktop automation
    -> Windows application/process discovery
    -> repeated short-lived PowerShell invocations
    -> rapid polling / retry / parallel execution
    -> PowerShell process storm and warning burst
    -> system-wide resource exhaustion or Windows instability
    -> complete hard freeze

I cannot yet confirm the exact internal retry or polling mechanism, but the evidence now points much more strongly toward the Browser / Windows application-discovery path than toward the repository being analyzed.

Relationship to the previous two incidents

All three incidents now show a consistent pattern:

| Incident | PowerShell startup events | Additional evidence | Associated Codex functionality |
| --------------------------- | ------------------------- | ----------------------------- | ------------------------------- |
| 2026-07-19, first incident | 321 | 52 WMI out-of-memory warnings | Codex process enumeration |
| 2026-07-19, second incident | 777 | 5 active execution contexts | Windows automation |
| 2026-08-04, third incident | 523 | 467 unique PIDs, 137 warnings | Browser / Windows app discovery |

The common factor across all three incidents is repeated PowerShell-based Windows process/application discovery under sustained Codex activity.

The latest incident makes it less likely that the issue is specific to one repository or one terminal command.

Hardware / OS evidence

As with the previous incidents:

• No new bugcheck dump was generated.
• No new LiveKernelReport was generated.
• No WHEA hardware errors were recorded.
• No new display-driver recovery event was recorded.
• No disk-related error indicating a storage failure was found.
• The shutdown was recorded as an abnormal shutdown rather than a normal Windows bugcheck.

This continues to provide no evidence of a GPU, SSD, RAM, or other hardware failure associated with the incident.

Possible secondary observation

ASUS GameFirst / GameTurbo.exe also changed the Windows power plan multiple times shortly before the freeze.

However:

• no corresponding GameTurbo error event was recorded;
• the correlation is much weaker;
• the PowerShell / Browser event storm is considerably more pronounced and directly precedes the freeze.

I therefore currently consider GameTurbo a secondary observation rather than the primary cause.

Current workaround

Until this is fixed, I am avoiding:

• Codex Browser control
• Chrome/browser automation through Codex
• Computer Use / desktop-control functionality
• multiple concurrent Codex tasks or sub-agents

For local web testing, I am instead using a single persistent terminal session with Playwright/browser CLI tools or manual browser inspection.

I also fully exit Codex after stopping tasks to reduce the possibility of background contexts resuming application discovery.

Current assessment

After three independent hard-freeze incidents, the evidence now strongly suggests that the failure is associated with the Codex Windows App Browser / desktop-control application's Windows discovery layer repeatedly creating short-lived PowerShell processes.

Under concurrent execution, polling, or error-retry conditions, the creation rate appears capable of becoming high enough to destabilize the entire Windows system.

I can provide the decoded PowerShell script, exported PowerShell Operational logs, relevant Event Viewer data, and the per-PID timeline if maintainers would find them useful.