›_ Codex Issues
Codex Issues / #29317

Windows app-server PowerShell AST parser can leak ~185GB commit memory and break RDP/RPC/SSH exec

Open 💬 4 comments Opened Jun 21, 2026 by lawyer112
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On a Windows host running Codex Desktop / app-server, the long-lived internal PowerShell AST parser process used by the Windows command-safety layer grew to about 185 GB of committed memory. This triggered Windows resource exhaustion and temporarily broke RDP, RPC, SSH exec, and local services. The machine later recovered without reboot after the offending process exited or was terminated.

This appears related to the Windows command-safety PowerShell parser discussed in #20510 and the broader desktop resource issues discussed in #27848, but this report includes concrete Windows Resource-Exhaustion-Detector evidence and a severe system-wide failure mode.

Environment

  • Product: Codex Desktop / app-server on Windows
  • Package version observed: OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0
  • OS: Windows host, accessed over RDP and OpenSSH
  • Codex process chain observed before mitigation:
  • Codex.exe
  • codex.exe app-server --analytics-default-enabled
  • powershell.exe
  • child helper node.exe ./mcp/server.bundle.mjs

The PowerShell child command line decoded to an internal helper whose comments identify it as:

Long-lived PowerShell AST parser used by the Rust command-safety layer on Windows.

What happened

The Windows host became partially unusable:

  • RDP stopped working; the user saw a black screen / failed desktop session.
  • RPC became unavailable.
  • SMB and service-control queries failed.
  • OpenSSH still accepted authentication, but could not create exec sessions:
exec request failed on channel 0
  • PowerShell startup failed intermittently with resource-related errors, including 0x800705AF.
  • Windows services such as Windows Error Reporting, AppXSVC, and ClipSVC failed because the system could not allocate enough resources / create threads.

The host later recovered without reboot after memory pressure cleared. Killing the Codex Desktop / app-server process tree stabilized the machine.

Windows event log evidence

Microsoft-Windows-Resource-Exhaustion-Detector, Event ID 2004, recorded the following process memory usage:

powershell.exe (26244) used 185,759,944,704 bytes
python.exe used about 1.8 GB
ToDesk.exe used about 677 MB

Earlier resource-exhaustion events in the same incident showed the same PowerShell process growing:

powershell.exe (26244) used 90,265,735,168 bytes
powershell.exe (26244) used 185,430,315,008 bytes
powershell.exe (26244) used 185,481,949,184 bytes
powershell.exe (26244) used 185,759,944,704 bytes

Related service failures after memory exhaustion included:

Windows Error Reporting Service stopped: page file too small to complete the operation
AppX Deployment Service failed: unable to create new service thread
Client License Service failed / timed out

Current workaround

I killed the Codex process tree on the affected host:

  • Codex.exe
  • codex.exe app-server
  • MCP node.exe children
  • the long-lived PowerShell AST parser child

After that, memory returned to normal and no Codex residual processes remained.

Expected behavior

The command-safety PowerShell parser should have bounded memory usage and should not be able to exhaust system commit memory. If the parser process grows unexpectedly, Codex should restart or kill it before it can destabilize the host.

Possible fixes

  • Add a memory limit / watchdog for the long-lived PowerShell AST parser.
  • Restart the parser after a bounded number of parse requests.
  • Avoid keeping a single unbounded long-lived PowerShell parser process on Windows.
  • Expose a configuration switch to disable the long-lived parser or fall back to per-command parsing.
  • Surface parser health in app-server logs so this failure mode is easier to diagnose.

Impact

This is high impact on Windows servers or remote workstations. A single Codex app-server helper process can make the host appear offline by breaking RDP/RPC/SSH exec even though the kernel and network stack are still partially alive.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

  • #29079
  • #27848

Powered by Codex Action

Necmttn · 2 months ago

The parser helper needs resource boundaries like any other long-lived service. I would track pid, parent session, command hash, parses served, heap/commit high-water mark, last request age, and kill reason. Then add a hard ceiling that recycles the helper before Windows resource exhaustion breaks unrelated services. The bug report has enough evidence to make this a watchdog test, not only a leak investigation.

---

_Generated with ax._

13360693986-droid · 2 months ago

Additional reproduction: long-running test succeeds, then Codex Desktop exec host fails with 0xC0000142

I hit what looks like the same Windows Desktop exec/helper failure mode, with one extra detail: the long-running child command can complete successfully first, and only then the Codex Desktop execution host enters a broken state.

Environment

  • OS: Windows 11
  • App: Codex Desktop
  • Codex Desktop package observed: OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0
  • PowerShell tested:
  • Windows PowerShell 5.1
  • PowerShell 7.6.3 installed via MSIX
  • Windows Terminal: Microsoft.WindowsTerminal 1.24.11321.0
  • Shells tested from Codex:
  • powershell.exe
  • pwsh.exe
  • cmd.exe

Reproduction

  1. In Codex Desktop on Windows, run a long Python test command, for example:

``cmd
.\.venv\Scripts\python.exe -m pytest tests -q
``

  1. The test command itself completes successfully:

``text
1633 passed, 158 subtests passed in ~66s
exit code 0
``

  1. Immediately run a trivial follow-up command in Codex:

``cmd
echo still-ok
``

  1. The follow-up command fails with:

``text
Process exited with code -1073741502
``

  1. After that, simple commands such as echo, cmd.exe /c echo ok, Get-Date, or git diff --check fail from Codex with the same exit code.

Additional observations

  • The failure originally appeared after PowerShell printed:

``text
The Win32 internal error "No process is on the other end of the pipe" 0xE9 occurred while setting the console window title.
``

  • Installing PowerShell 7.6.3 did not fix it. Running the same long test through pwsh still reproduced the failure.
  • Windows Terminal is already at the latest stable release, so this does not appear to be caused by an outdated Windows Terminal install.
  • The issue can also reproduce when the long test is launched through cmd.exe, so it is not only a user-selected PowerShell shell problem.
  • Restarting Codex Desktop restores command execution.
  • Clearing .codex sandbox/cache is not required to recover and can make the situation worse.
  • I had recently run multiple Codex CLI / codex exec workflows, which may increase the chance of triggering the issue, but the repro above happened inside Codex Desktop and leaves the Desktop exec host broken.

Expected behavior

After a child command completes successfully, Codex Desktop should remain able to launch subsequent commands.

Actual behavior

The child command succeeds, but the Codex Desktop execution host enters a broken state where every subsequent command fails with 0xC0000142 / -1073741502.

Workarounds tested

  • Restarting Codex Desktop restores the execution host.
  • Avoiding long-running/high-output verification commands inside Codex Desktop reduces the chance of triggering the issue.
  • Running long tests outside Codex Desktop in a normal terminal is safer.
  • Updating PowerShell and Windows Terminal did not resolve the issue.
HSUABI · 28 days ago

Additional independent evidence from a newer Windows Desktop build

I observed what may be the same or an adjacent Windows PowerShell lifetime/resource-exhaustion failure. I cannot confirm that the leaking process was the long-lived AST parser described in this issue, because I deliberately did not retain or publish raw command lines. The evidence does show completed Codex shell activity followed by a PowerShell process remaining alive for about two hours and exhausting system commit.

Environment

  • Codex Desktop Appx: 26.721.4979.0
  • Bundled Codex CLI: 0.146.0-alpha.3.1
  • Windows 11 Enterprise, build 26100
  • Windows PowerShell 5.1
  • Physical RAM: 16 GB
  • WSL2 and Docker Desktop present

Windows Event ID 2004 evidence

2026-07-29 18:13 KST

  • System commit: 48.743 / 48.766 GB (about 99.95%)
  • powershell.exe PID 19268: 19,956,244,480 bytes
  • vmmemWSL: 4,774,883,328 bytes
  • PID 19268 start time: 16:11:39 KST
  • The process start time matched a long Codex Desktop API/MR automation workflow.
  • The corresponding Codex shell-tool calls had returned, but the PowerShell process remained alive for about two hours.
  • Codex became unusable around 18:16 KST.

Earlier event on 2026-07-29 00:42 KST

  • powershell.exe PID 9120: 6,182,174,720 bytes
  • powershell.exe PID 38900: 5,206,028,288 bytes
  • vmmemWSL: 5,803,929,600 bytes

A privacy-preserving correlation pass retained only timestamps, tool names, byte lengths, and SHA-256 metadata. It did not retain commands, outputs, call IDs, environment values, tokens, or credentials.

Causality boundary

  • This evidence does not distinguish an internal command-safety AST parser leak from a shell-child/stdout/stderr/handle finalization deadlock.
  • Tool return timing and process lifetime are strongly correlated, but do not prove the internal root cause.
  • WSL was not the largest consumer in the critical event; this does not prove WSL was uninvolved, only that it was not the direct 19.96 GB process.

Expected behavior

After a shell tool returns or times out, Codex should close or explicitly account for its child process tree and pipe handles. Long-lived internal helpers should have bounded memory and be recycled before system commit exhaustion.

Local mitigation and validation

I installed a fail-closed local boundary using a Windows Job Object with KILL_ON_JOB_CLOSE, bounded runtime/memory/output, concurrent stdout/stderr draining, and a one-minute watchdog. The watchdog terminates only a confirmed Codex-lineage PowerShell orphan after all conditions hold: at least 4 GB, at least 10 minutes, three consecutive low-CPU samples, no active child, and not interactive/scheduled/service/excluded.

A synthetic suite passed 15/15, including exact orphan-tree termination and preservation of CPU-active, interactive, unrelated, child-bearing, and service processes. This is only a local mitigation, not a product fix.

I can provide redacted Event ID 2004 exports and metadata-only process/timing evidence through an approved secure channel. I will not publish raw Codex transcripts, command lines, environment values, credentials, or unrelated crash dumps.