Codex on Windows can leave large numbers of orphaned dotnet.exe processes after .NET CLI work
What version of the Codex App are you using (From “About Codex” dialog)?
26.313.41514
What subscription do you have?
Pro
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Date observed: March 21, 2026
Environment:
- Windows 11 Pro, Microsoft Windows NT 10.0.26200.0 x64
- Local .NET repository
- This was not a CI run, watcher session, test session, or long-running script workflow
Summary:
Codex on Windows appears able to leave behind large numbers of orphaned dotnet.exe processes after performing ordinary .NET CLI work. In this instance, after running standard repository setup/build commands, approximately 495 dotnet.exe processes remained running and had to be cleaned up manually.
Important context:
- This happened in a local Windows .NET repo
- I do not normally run tests, scripts, or file watchers in this repo
- I believe this happens regularly with Codex on Windows and is not necessarily specific to this exact workflow
- In this case, the buildup happened while Codex was running normal .NET CLI commands during setup/validation work
Approximate orphaned process count:
- ~495 dotnet.exe processes were left running
Commands Codex had been running:
- dotnet new
- dotnet sln
- dotnet restore
- dotnet build
Observed behavior:
- Hundreds of dotnet.exe processes remained alive after Codex finished or after commands had already failed/completed
- These processes were not expected and did not correspond to a normal user workflow in this repo
- The issue does not appear limited to intentional long-running activity like watchers or background scripts
Cleanup required:
The orphaned processes did not clear on their own. Manual cleanup was needed:
- dotnet build-server shutdown
- forced process termination of remaining dotnet.exe processes
Cleanup that worked:
- dotnet build-server shutdown
- Get-Process dotnet -ErrorAction SilentlyContinue | Stop-Process -Force
Impact:
- Large unexpected process buildup
- Potential CPU/memory drain
- User had to manually clean up the machine after Codex activity
What would help:
- Codex should avoid leaving background dotnet hosts/build servers behind
- Codex should be more careful with repeated or parallel .NET CLI invocations on Windows
- Codex should detect and clean up orphaned tool processes before ending a task
What steps can reproduce the bug?
Codex on Windows appears able to leave behind large numbers of orphaned dotnet.exe processes after ordinary .NET CLI work. This does not seem limited to tests, watchers, or long-running scripts. In this instance, Codex was doing standard repo setup/build work in a local .NET repo, and hundreds of dotnet.exe processes remained alive afterward and had to be cleaned up manually with dotnet build-server shutdown plus forced process termination.
What is the expected behavior?
100s of .NET Host instances running even during and after codex work.
Additional information
I think this is a common occurrence for both the CLI and Codex app. This is just a report of details from one case.
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
This may be related to a broader Windows child-process cleanup issue, but I’m leaving this open because the repro here is narrower and more specific. In this case, the issue is ordinary local Windows .NET CLI work in a .NET repo, where roughly 495 dotnet.exe processes were left running after commands like dotnet new, dotnet sln, dotnet restore, and dotnet build.
The closest related reports I found are:
#15379, which is about orphaned child processes persisting after the Codex parent exits.
#14949, which is about an aborted Windows shell task leaving orphaned child processes and potentially resuming into a process storm on restart.
#14962, which is about orphaned process pairs continuing after terminal closure and burning CPU.
Older related reports like #7932 and #4337 also seem to point at the same general family of child-process/job-control cleanup problems.
That said, this issue appears to be a distinct Windows + .NET CLI manifestation of the problem rather than an exact duplicate of any one report above. If maintainers determine it shares the same root cause, I’m happy for it to be linked or closed then.
I had this happen constantly while working on a project that leveraged the toolchains of most programming languages (at points surpassing 15000 dangling processes), they do not appear to be interested in expending any effort fixing the way the models or the app/tui handle this. The easiest bandaid is to tell the agent and its subagents to keep track of PIDs and clean up after themselves. I've since made a new local user for codex to work from to limit the blast radius
I'm still seeing this on Codex
26.415.20818, installed and tested today. A single turn might generate 100+dotnet.exeprocesses which causes Codex to trip on itself locking build outputs etc. Once told to clean up after itself, it does by happily terminating all dotnet.exe processes 😅. But this shouldn't be needed, obviously.Also encountering this, pretty annoying as it prevents codex from building code and running unit tests automatically