Repository navigation
Windows Codex app spawns 12–13 git.exe processes per second and recreates invalid empty .git directories #33450
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.22631.0 x64 (Windows 11)
What issue are you seeing?
The Windows Codex desktop app enters a continuous Git process-spawning loop when local Codex project entries are not valid Git repositories.
I traced process creation at 50 ms intervals. During a 15-second period when Codex was otherwise idle:
- The main
ChatGPT.exeprocess directly launched 193git.exeprocesses. - This is approximately 12.9 direct Git launches per second.
- There were 443 total process starts during the interval.
- Many Git processes launched additional
git.exeandconhost.exechildren.
During a separate 70-second trace:
- 620
git.exestarts - 621
git.exestops - 452
conhost.exestarts - 452
conhost.exestops
The initial Git processes were confirmed as direct children of the main ChatGPT.exe, not a Codex command runner, PowerShell tool call, or user-invoked terminal.
The repeatedly executed command is:
"C:\Program Files\Git\cmd\git.exe" -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel
Additional Git commands include:
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false rev-parse HEADgit.exe -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelaingit.exe -c core.hooksPath=NUL -c core.fsmonitor=false remote -vgit.exe config --null --get core.fsmonitor
The affected non-Git project locations contain completely empty .git directories. They have no HEAD, config, index, objects, commondir, or gitdir.
Running git rev-parse --show-toplevel manually in those locations fails with exit code 128:
fatal: not a git repository (or any of the parent directories): .git
I renamed the empty .git directories to timestamped backups. The already-running app continued launching Git at approximately 12.8 times per second.
I then fully restarted only the Codex/ChatGPT desktop app. Codex recreated the empty .git directories and the new main ChatGPT.exe process immediately resumed the loop:
- 182 direct Git launches in 15 seconds
- Approximately 12.2 launches per second
- 432 total process starts
The process storm causes unnecessary CPU/process activity, additional Microsoft Defender scanning, system heating, fan noise, and reduced responsiveness. Program Compatibility Assistant CPU spikes have also been visible in Task Manager, although my two short PCA sampling windows happened to catch that service idle, so I am not claiming a directly measured PCA causal relationship.
What steps can reproduce the bug?
- Install or launch Codex desktop app version
26.707.9981.0on Windows. - Open a local Codex project that is not a Git repository.
- Allow Codex to sit idle with no agent or command actively running.
- Inspect the process tree using Task Manager, Process Explorer, or process-creation tracing.
- Observe the main
ChatGPT.exerepeatedly launchinggit.exe rev-parse --show-topleveland related Git commands. - Inspect the affected project directory and observe an empty, invalid
.gitdirectory. - Rename the empty
.gitdirectory and restart Codex. - Observe Codex recreate the empty
.gitdirectory and immediately resume launching approximately 12–13 Git processes per second.
For comparison, separate valid Git projects on the same computer return exit code 0 from git rev-parse --show-toplevel and contain normal Git metadata.
What is the expected behavior?
For a local directory that is not a valid Git repository, Codex should:
- Detect the Git failure once.
- Treat the directory as a normal non-version-controlled local project.
- Avoid creating an empty or invalid
.gitdirectory. - Cache the non-Git result or use an appropriate retry backoff.
- Recheck only after a relevant filesystem change, explicit refresh, or sufficiently long interval.
- Avoid continuously spawning
git.exeandconhost.exeprocesses while idle.
When Codex is idle and no task is running, CPU usage and background subprocess activity should return close to zero.
Additional information
Git version:
git version 2.34.1.windows.1
No usernames, private repository names, conversation contents, or unrelated local paths are included in this report.
Potentially related issues:
- Codex Windows App keeps spawning
git.exe status --porcelain=v1 -zand leaves orphangit.exe/conhost.exeprocesses #17229 — Windows app repeatedly spawninggit.exeandconhost.exe - Codex App enters high CPU loop when project list contains non-git entries #19201 — High-CPU loop with non-Git project entries
- Windows: Codex spawns many Git for Windows processes causing sustained high CPU after recent update #22085 — Windows Git process spawning and sustained CPU
The additional observations in this report are:
- Exact measured rate of approximately 12–13 direct Git launches per second
- Parent process confirmed as the main
ChatGPT.exe - The behavior continues while completely idle
- Empty
.gitdirectories contain no valid repository metadata - Codex recreates the invalid empty
.gitdirectories after a complete app restart - Renaming the empty directories without restarting does not stop the cached loop
- The loop persists across a new
ChatGPT.exeprocess instance
Activity
github-actions commentedon Jul 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
workspace-writesandbox creates an empty<workspace>\.gitdirectory in a workspace that is not a Git repository #32872Powered by Codex Action
Burnrate commentedon Jul 16, 2026
The also makes the antimalware service executable that is running the realtime scanning use a lot of cpu. Together with the Program Compatibility Assistant it can push my cpu up to 100 C and cause thermal throttling.
rwang23 commentedon Jul 16, 2026
This is consistent with a current Windows desktop investigation: the AppX activation path can bypass a process-local launcher
PATH, so the app may reach the real Git executable and create visible console/ConPTY surfaces even when a wrapper was used for the normal launch path.For the visual symptom only, I published a portable local mitigation here:
https://github.com/rwang23/codex-windows-console-guard
It uses reversible process-local Git/PowerShell/CMD wrappers and a native guard for narrowly identified Codex-owned windows. The guard now covers both
ConsoleWindowClassandPseudoConsoleWindowcases, but it deliberately does not suppress arbitrary terminals or mutate Git/registry/PATH state.Important scope: this does not fix the 12+ Git launches per second, recreate/repair invalid
.gitdirectories, or remove the CPU/Defender cost. It only prevents the visible launcher windows while upstream fixes the project-discovery/polling loop and child-process lifecycle.suiyuebaobao commentedon Jul 22, 2026
The 12–13
git.exeprocesses per second and invalid empty.gitrecreation here closely match the process storm 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.
bobbanj commentedon Jul 24, 2026
I believe I've reproduced a related but distinct manifestation of the same underlying issue.
Unlike the invalid .git / retry-loop scenarios described above, this occurred in a completely valid Git repository.
Starting from a clean baseline (~0–4 git.exe processes), a single Codex task gradually accumulated approximately 257 concurrent Git processes.
The oldest Git processes remained alive for 105–127 minutes.
The process count then remained on a stable plateau around 255–259 until the task was stopped.
Stopping the active task immediately reduced the Git process count:
257 → 26 → 4
I reproduced this twice from a clean baseline.
This suggests that, in addition to the retry loop already discussed here, there may also be a task-lifecycle issue where Git child processes remain alive for the duration of long-running work.
Update after testing version 26.721.41059
I reran the same monitoring that previously reproduced the issue (5-second sampling of Git process count, oldest Git process age, and total process count).
On the previous version, a single long-running task accumulated approximately 255–273 concurrent git.exe processes with process lifetimes exceeding 100 minutes.
On 26.721.41059 I have not been able to reproduce that behaviour so far. Git activity now appears as short-lived bursts (typically 0–3, occasionally up to 5 processes), with process lifetime remaining near zero before returning to baseline.
I'll continue running longer stress tests, but the behaviour is significantly improved compared to the previous version.
Pygmalion03 commentedon Aug 1, 2026
Confirming this on Windows 11 with the exact same Codex App version:
26.707.9981.0.The process storm had already subsided by the time I captured a short process-start trace, but Microsoft Sysinternals RAMMap v1.63 showed the cumulative system impact:
git.exe, 104,232conhost.exe, 6,012cmd.exe, and 4,319powershell.exeSystem commit was near the limit and paging made the machine effectively unusable. Even after the launch storm stopped, the accumulated page-table/commit pressure did not promptly return to normal; a reboot was needed to fully recover.
This matches the Git command family and app version reported here. The additional evidence is that a long-running Git/conhost process-creation storm can accumulate several gigabytes of page-table overhead, so the eventual symptom may look like an unexplained Windows/kernel memory leak rather than high memory owned by a currently visible process.
I did not capture the live parent chain after the storm had stopped, so I am not claiming more than the evidence supports. No usernames, project paths, repository names, or conversation data are included.
jcgennaro commentedon Aug 3, 2026
This just happened to me. Uber slowdown, hundreds of git and git lfs processes in task manager. Had to forcibly restart. Not a good experience.
5168413518 commentedon Oct 8, 2026
Another data point for idle Codex Git spawning, with a different trigger from the invalid/empty
.gitcase: an unnecessary valid ancestor Git repository covered the user profile and several nested Codex project folders.Confirmed Windows 10 workaround: accidental Git repo at
%USERPROFILE%was causing idle Codex Git scansI reproduced high idle CPU/heat in the Microsoft Store ChatGPT/Codex desktop app 26.1002.7124.0 on Windows 10. No local agent task was running; fully exiting the app reduced the load.
Evidence before the change
ChatGPT.exewas launching repeatedgit.exesubprocesses. One captured command wasgit ... ls-files --cached -z -- AppData/Local/Packages/....git -C %USERPROFILE% rev-parse --show-toplevelresolved to the entire user-profile directory.%USERPROFILE%\.gitexisted (withHEAD/ normal Git structure, but no commits, index, or remotes). Persisted Codex project directories nested under%USERPROFILE%\.codex\.chatgpt-projects\...thus inherited the profile-level Git root..gitand was unaffected.Reversible workaround that worked here
%USERPROFILE%\.gitis actually needed. Do not rename/remove it if your home directory is intentionally a Git repository.%USERPROFILE%\.gitto a timestamped.git_backup_YYYY-MM-DD; do not delete it.After: 0
git.exePIDs in 60 consecutive samples over ~13 seconds, and essentially zero CPU time attributable to the idle ChatGPT process group during that sample. The affected laptop's temperature improved. Git, Codex CLI, and an actual Work Local Git read test in the independent development repo still worked; no project files/Git history were changed.This is one confirmed local mitigation, not an upstream fix. It does not establish the cause of unrelated
taskkill.exe/WMI polling bugs or UI freezes. The likely product improvement is to avoid scanning an accidentally inherited ancestor repo outside the saved workspace scope, and bound/debounce background Git refreshes.— Пчеличко (Pchelichko)