[Windows] Codex Desktop spawns hundreds of lingering taskkill.exe processes during agent work and freezes the OS

Start by reproducing the burst during Codex Desktop agent work on a Windows Git-backed workspace, using the provided PowerShell process query. Investigate the Windows subprocess cleanup path in Codex Desktop or app-server, focusing on overlapping taskkill.exe launches and unreaped processes. Done means cleanup processes exit or are reaped without accumulating, and agent work no longer makes the Windows session unresponsive.

Summary

Codex Desktop on Windows rapidly spawns hundreds of taskkill.exe /PID <pid> /T /F processes during ordinary agent work. The taskkill.exe processes do not exit promptly, accumulate in large batches, and eventually make the entire Windows session effectively unusable.

This is not only a Codex UI freeze. During severe incidents, Task Manager cannot be opened, the desktop and other applications stop responding, and the machine must be restarted remotely or forcibly.

Environment

• Codex Desktop: 26.715.8383.0
• Package: OpenAI.Codex_26.715.8383.0_x64__2p2nqsd0c76g0
• Windows: 25H2, build 26200.8655, x64
• Native Windows workspace and PowerShell
• Reproduces while the Diff/Review panel is closed

Steps to reproduce

1. Launch Codex Desktop on Windows.
2. Open a Git-backed local workspace.
3. Start ordinary agent work that runs local shell/tool commands.
4. Keep the Diff/Review panel closed.
5. Sample live taskkill.exe processes:

   Get-Process taskkill -ErrorAction SilentlyContinue |
     Select-Object Id, StartTime, CPU, Responding
   

6. Observe a rapid burst of hundreds of simultaneously alive taskkill.exe processes.

The issue is bursty and closely correlated with starting agent work.

Observed evidence

Snapshot 1

At 00:40:19:

• 321 simultaneously alive taskkill.exe processes
• Oldest surviving process started at 00:39:24
• Newest process started at 00:40:19
• New processes were still being created at the time of the sample

Representative command line:

C:\Windows\System32\taskkill.exe /pid <pid> /t /f

Snapshot 2

A second agent-work run produced another distinct burst:

The burst began around 00:45:20; the newest process in that burst was created at 00:45:30. Spawning stopped temporarily, but 191 processes were still alive eight seconds later.

The monitoring command itself creates one Codex shell command, but cannot account for hundreds of taskkill.exe processes.

Controls already tested

• Closing the Diff/Review panel does not stop the process storm.
• The storm begins again when new agent work is dispatched.
• The repository's generated Python cache files were removed and ignored; the behavior still reproduced.
• Restarting Windows temporarily clears the accumulated processes, but the problem returns during later Codex work.

Expected behavior

Codex should:

• create at most one short-lived cleanup process per completed/timed-out child command;
• wait for or reap cleanup processes correctly;
• avoid launching overlapping cleanup batches for already-terminated targets;
• never accumulate hundreds of live taskkill.exe processes;
• never degrade the entire Windows shell or prevent Task Manager from starting.

Impact

This has become frequent enough to block development. Once enough processes accumulate:

• the entire Windows desktop becomes unresponsive;
• Task Manager may not open;
• local restart commands may not execute promptly;
• only a delayed remote restart or forced reboot recovers the machine.

Current hypothesis

This appears to be a Windows subprocess lifecycle/cleanup problem in Codex Desktop or app-server. Codex starts taskkill /PID ... /T /F cleanup commands, but the cleanup processes themselves remain alive while additional cleanup commands are launched. Repeated agent runs compound the backlog until Windows becomes resource-starved.

Related issues

• #16374 — Windows shell/UI freeze and hundreds of zombie child processes
• #17610 — timeout waiting for child process to exit / lingering process tree
• #20200 — countless Git child processes and machine crashes in large repositories
• #21957 — confirms the Windows app-server internally invokes taskkill /T /F /PID

I have a local black-box monitor collecting one-second system counters and process-creation auditing. I can provide a sanitized process-creation CSV, target-PID frequency summary, and additional timestamps if maintainers specify the preferred attachment format.