Codex appears to leave orphaned git.exe processes on Windows.

Open 💬 4 comments Opened Jun 2, 2026 by DasEtwa

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.527.7698.0

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

In one Codex App session on Windows, Codex opened many git.exe and Windows shell processes. After the task/session ended, several of these processes were still running.

This happened while I was asking Codex to make several changes and put each completed step/change into a PR. During that workflow, Codex repeatedly ran Git and shell commands.

At one point, I had around 30 git.exe processes open at the same time, plus multiple Windows shell processes. Today I manually closed around 20 git.exe processes and around 10 Windows command/shell processes.

Codex sometimes says that a process was closed, but Task Manager / PowerShell still shows the process running.

What steps can reproduce the bug?

I am using the Codex Desktop App from the Windows Store on Windows 10 Pro.

I do not have an exact minimal reproduction yet, but this happened during a normal Codex App workflow in my project:

1 I opened my project in the Codex Desktop App.
2 I gave Codex multiple tasks and asked it to put each completed step/change into a PR.
3 Codex ran Git commands and Windows shell commands during the session.
4 After a while, I noticed that many processes were still open.
5 Task Manager / PowerShell showed around 30 git.exe processes and multiple Windows command/shell processes still running.
6 Today I manually closed around 20 git.exe processes and around 10 Windows processes.
7 In some cases Codex said that a process was closed, but the process was still visible and running in Windows.

Example from PowerShell:

Remaining process: git.exe
PID: 24612
Started: 2026-06-02 18:21:10
Path: C:\Program Files\Git\mingw64\libexec\git-core\git.exe

I am not sure if the PR workflow specifically triggers the issue, but it happened while Codex was repeatedly creating/working with PRs and running Git commands.

What is the expected behavior?

Codex should clean up all Git, shell, and child processes that it starts during a session.

If Codex starts git.exe, cmd.exe, powershell.exe, node.exe, or other child processes, it should track their PIDs and terminate them when they are no longer needed.

If Codex says that a process was closed, the process should actually be terminated and no longer appear in Task Manager or PowerShell.

Additional information

_No response_

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#24681

Powered by Codex Action

DasEtwa · 2 months ago

I think this is related, but not an exact duplicate.

My issue is not mainly about file rewrite failures or “user-mapped section open” errors. My issue is about Codex leaving many orphaned git.exe and Windows shell processes alive after a session/PR workflow.

Codex sometimes reports that a process was closed, but Windows Task Manager / PowerShell still shows the process running.

So this may share an underlying Windows process-management cause, but the symptom and expected behavior are different. Could this be tracked as a separate process-cleanup/orphaned-child-process issue?

brepublic · 2 months ago

I am seeing what appears to be the same issue, but at a much larger scale on Windows 11 Pro with 32 GB of RAM.

After using the Codex Desktop App, my physical memory usage eventually reached approximately 29.9 / 31.2 GB (95–96%).

RAMMap showed:

Page Table: 9,359,280 KB
Unused / Active: 9,185,084 KB
Nonpaged Pool: 3,376,648 KB
Process Private: only approximately 5 GB

The RAMMap Processes tab contained an extremely large number of git.exe and conhost.exe entries with:

Private: 0 KB
Standby: 0 KB
Modified: 0 KB
Page Table: usually 8–32 KB

These entries were no longer visible as normal running processes in Task Manager or Get-Process.

I also compared the Windows process-object performance counter with the number of live processes:

$objects = [int64](Get-Counter '\Objects\Processes').CounterSamples.CookedValue
$live = @(Get-Process).Count

The result was:

ProcessObjects: 289,371
LiveProcesses:       345
Difference:      289,026

This suggests that approximately 289,000 terminated process objects were still being retained. The retained git.exe and conhost.exe objects account for several gigabytes of page-table memory and appear to be the main reason the system memory became exhausted.

This is slightly different from simply having a few live orphaned git.exe processes: most of these processes appear to have terminated, but their process objects and page tables were not released.

Rebooting clears the retained objects and restores the memory. I have saved a RAMMap .RMP snapshot and screenshots and can provide them if they would help with diagnosis.

I do not yet have a minimal reproduction, but Codex was repeatedly launching Git and shell commands before the object count accumulated.

suiyuebaobao · 1 month ago

The orphaned git.exe behavior reported here closely matches the process churn I reproduced.

I published a single-file Windows launcher for the original Microsoft Store/MSIX Codex app:

Repository: https://github.com/suiyuebaobao/codex-git-refresh-workaround
Direct download: https://raw.githubusercontent.com/suiyuebaobao/codex-git-refresh-workaround/main/Codex-Git-Disabled.cmd

It starts Codex with a process-scoped GIT_DIR=NUL. On my machine, the stable trace changed from 247 new git.exe and 137 new taskkill.exe processes per 10 seconds to 0 and 0 over 15 seconds; WMI Provider Host fell from about 6.6% to 0.9%.

Usage: fully exit Codex from the Windows system tray, then run the script.

This is an unofficial workaround, not an upstream fix. It deliberately disables or limits Review, Changes, branch detection, commit, and other Git-backed Codex features. It does not patch Codex, modify repositories or Git configuration, write system environment variables, require elevation, terminate processes, or remove chat history. Launching Codex normally restores Git integration.