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

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:

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

1. 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:

| Time | Alive taskkill.exe | Started in previous 10s | Started in previous 60s |
|---|---:|---:|---:|
| 00:45:27 | 152 | 152 | 152 |
| 00:45:30 | 189 | 189 | 189 |
| 00:45:32 | 203 | 178 | 203 |
| 00:45:34 | 202 | 137 | 202 |
| 00:45:36 | 196 | 96 | 196 |
| 00:45:38 | 191 | 56 | 191 |

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.