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

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.