›_ Codex Issues
Codex Issues / #33450

Windows Codex app spawns 12–13 git.exe processes per second and recreates invalid empty .git directories

Open 💬 7 comments Opened Jul 16, 2026 by Burnrate
💡 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.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.exe process directly launched 193 git.exe processes.
  • 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.exe and conhost.exe children.

During a separate 70-second trace:

  • 620 git.exe starts
  • 621 git.exe stops
  • 452 conhost.exe starts
  • 452 conhost.exe stops

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 HEAD
  • git.exe -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelain
  • git.exe -c core.hooksPath=NUL -c core.fsmonitor=false remote -v
  • git.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?

  1. Install or launch Codex desktop app version 26.707.9981.0 on Windows.
  2. Open a local Codex project that is not a Git repository.
  3. Allow Codex to sit idle with no agent or command actively running.
  4. Inspect the process tree using Task Manager, Process Explorer, or process-creation tracing.
  5. Observe the main ChatGPT.exe repeatedly launching git.exe rev-parse --show-toplevel and related Git commands.
  6. Inspect the affected project directory and observe an empty, invalid .git directory.
  7. Rename the empty .git directory and restart Codex.
  8. Observe Codex recreate the empty .git directory 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:

  1. Detect the Git failure once.
  2. Treat the directory as a normal non-version-controlled local project.
  3. Avoid creating an empty or invalid .git directory.
  4. Cache the non-Git result or use an appropriate retry backoff.
  5. Recheck only after a relevant filesystem change, explicit refresh, or sufficiently long interval.
  6. Avoid continuously spawning git.exe and conhost.exe processes 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:

  • #17229 — Windows app repeatedly spawning git.exe and conhost.exe
  • #19201 — High-CPU loop with non-Git project entries
  • #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 .git directories contain no valid repository metadata
  • Codex recreates the invalid empty .git directories after a complete app restart
  • Renaming the empty directories without restarting does not stop the cached loop
  • The loop persists across a new ChatGPT.exe process instance

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32324
  • #33264
  • #32872

Powered by Codex Action

Burnrate · 1 month ago

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 · 1 month ago

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 ConsoleWindowClass and PseudoConsoleWindow cases, 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 .git directories, 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 · 1 month ago

The 12–13 git.exe processes per second and invalid empty .git recreation 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 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.

bobbanj · 1 month ago

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 · 26 days ago

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:

  • 32 GB physical RAM
  • approximately 9.63 GB in Page Table
  • 309,750 rows in RAMMap's Processes view, versus roughly 340 live processes
  • historical image counts included 188,302 git.exe, 104,232 conhost.exe, 6,012 cmd.exe, and 4,319 powershell.exe
  • one surviving command line was:

``
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false remote -v
``

System 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 · 25 days ago

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.