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

Activity

1. Ray-315

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jul 18, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   performance

   subagentIssues involving subagents or multi-agent featuresIssues involving subagents or multi-agent features

   tool-callsIssues related to tool callingIssues related to tool calling

   on Jul 18, 2026
3. github-actions commented on Jul 18, 2026

   

   github-actionsBot

   on Jul 18, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows][26.715.3651.0] Cold launch spawns 300+ taskkill.exe/conhost.exe and freezes the whole PC #34025
   • [Windows][Desktop 26.707.12708.0] ChatGPT.exe spawns hundreds of taskkill.exe/conhost.exe processes, causing WMI storms and DWM degradation #33776
   • Windows Codex desktop app spawns hundreds of taskkill.exe and conhost.exe during local tool execution #33778
   • Built-in Agent subsystem enters a runaway loop, repeatedly running taskkill and launching conhost.exe, maxing out the CPU #34001

   Powered by Codex Action
4. CAPTW commented on Jul 19, 2026

   

   CAPTW

   on Jul 19, 2026

   More actions

   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.
5. Ray-315 commented on Aug 4, 2026

   

   Ray-315

   on Aug 4, 2026

   Author

   More actions

   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.