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.