Repository navigation
[Windows] Orphaned git.exe processes persist in 26.707.9981.0 and correlate with kernel pool growth #33264
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.707.9981.0
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
The Windows Codex/ChatGPT desktop app repeatedly spawns local Git metadata commands even when I have not requested any Git operation.
Observed commands include:
git status --porcelaingit rev-parse HEADgit remote -vgit config --null --get core.fsmonitor
I confirmed that a newly created git.exe process had the main ChatGPT.exe process as its direct parent. The short-lived parent/helper processes exit, but many git.exe processes remain alive for several minutes as orphaned processes.
During approximately two minutes of monitoring:
- The number of live
git.exeprocesses increased from 31 to 36. - Git processes consumed approximately 1.22 GB of private memory.
- Git processes held approximately 3,349 handles.
- Git working set was approximately 245 MB.
- Nonpaged pool increased from approximately 1.09 GB to 1.40 GB.
- Paged pool increased from approximately 856 MB to 894 MB.
The kernel pool growth is temporally correlated with the repeated Git/conhost process creation. I cannot attribute every byte of kernel pool growth to Git without pool-tag tracing, but the user-mode Git process and handle accumulation is directly observable.
No GitHub remote or authentication is configured for the active workspace. The observed commands are local metadata checks and should not require GitHub connectivity.
What steps can reproduce the bug?
Feedback ID: 019f6440-966a-76b1-8e36-1ab349c360d9
What is the expected behavior?
No response
Additional information
App package:
OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
Selected executable:
app\ChatGPT.exe
This appears closely related to the following issues, but it is still reproducible in the newer 26.707.9981.0 build and includes measured memory, handle, and kernel-pool growth:
- Codex Windows App keeps spawning
git.exe status --porcelain=v1 -zand leaves orphangit.exe/conhost.exeprocesses #17229 — repeatedgit.exe statusand orphanedgit.exe/conhost.exe - Windows desktop app triggers multiple git.exe add -A processes when opening a project/chat, causing severe CPU and disk usage #20933 — multiple Git processes triggered by opening a project/chat
- Windows: Codex spawns many Git for Windows processes causing sustained high CPU after recent update #22085 — sustained high resource usage from repeated Git for Windows processes
- Windows 26.429 desktop becomes unresponsive with long threads, MCP auto-start duplicates, and non-Git workspace warnings #20867 — repeated Git metadata work in non-Git workspaces
The active workspace has no configured Git remote. GitHub authentication or remote connectivity should therefore not be required for reproduction.
Activity
github-actions commentedon Jul 15, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
suiyuebaobao commentedon Jul 22, 2026
The persistent orphaned
git.exeprocesses and downstream pool growth here closely match the process churn I reproduced.I published a single-file Windows launcher for the original Microsoft Store/MSIX Codex app:
It starts Codex with a process-scoped
GIT_DIR=NUL. On my machine, the stable trace changed from 247 newgit.exeand 137 newtaskkill.exeprocesses 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.
Kingnamji commentedon Jul 22, 2026
Update from my Windows test environment:
I have confirmed that the issue is still reproducible as repeated short-lived and sometimes orphaned
git.exeprobes launched by the Codex/ChatGPT desktop app. The recurring commands include:git rev-parse HEADgit rev-parse --git-dirgit remote -vgit config --null --get core.fsmonitorgit status --porcelainAs a temporary local mitigation, I run two narrow PowerShell guards at logon:
git add, commit, push, or other normal write operations..gitmetadata in affected user workspaces. It leaves normal, non-empty repositories untouched.Latest observation:
rev-parse --git-dirorphan pattern.git.exeprocesses dropped from 9 to 0.This reduces the risk of long-lived orphaned processes accumulating handles/memory, but it is only a reactive workaround. It does not stop the desktop app from creating rapid short-lived Git probes in the first place, and it is not an upstream fix.
Could the team please investigate why the Windows desktop app repeatedly spawns these Git discovery/status probes, and why some can outlive their parent process? A built-in option to disable Git integration, or a fix to prevent orphaned probes, would be preferable to external process monitoring.