Codex Windows App keeps spawning about 1000 git command per minute NON STOP

[msg7086]

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

Codex
26.429.20946
© OpenAI

What subscription do you have?

Enterprise

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

I captured Process Create events under parent Codex.exe and counted 461 git.exe command runs per 30 seconds, so 900+ runs per minute.

Rotating among below commands

C:\Programs\SmartGit\git\bin\git.exe write-tree
C:\Programs\SmartGit\git\bin\git.exe add -u
C:\Programs\SmartGit\git\bin\git.exe add -- (redacted-file-names-under-playground-directory)
C:\Programs\SmartGit\git\bin\git.exe status --porcelain=v1 -z
C:\Programs\SmartGit\git\bin\git.exe rev-parse --git-path index
C:\Programs\SmartGit\git\bin\git.exe add -A
C:\Programs\SmartGit\git\bin\git.exe ls-files --others --exclude-standard -z

Logfile of 30 seconds.csv

What steps can reproduce the bug?

Open Codex and stay at Playground project without opening any conversation. Won't stop if I create a new conversation. Won't stop if I restart the app. Stops when I completely exit Codex app and its system tray icon.

What is the expected behavior?

Codex won't hammer my computer with hundreds of git calls non-stop.

Additional information

No response

[github-actions]

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

• Codex App ghost snapshot runs git add -A on trusted home directory and fills disk with tmp_pack files #19588
• Codex App enters high CPU loop when project list contains non-git entries #19201
• Codex Desktop renderer CPU loop when projectless/chat root is not a git repository #19568
• Codex App: non-git saved workspace roots can trigger renderer high CPU and Git warning loops #19115

Powered by Codex Action

[msg7086]

Similar to #17394 but can't say for sure it's the same situation. The w/a in that ticket didn't work.

I found a w/a that worked for me, that is to create .gitignore in the project with * in it, to exclude all files in the directory. Once this is done, no more git process hammering.

[monk-boop]

This didn't work. I'm getting hammered by github popups

[msg7086]

The w/a applies specifically to the issue I was hit. Maybe you hit a different bug.

For me once applying the w/a it stops hammering, then I can delete the * and the issue won't come back.

[jrbdev1]

I'm experiencing this issue as well. Windows 11 v 25H2, build 26200.8329.

Unless I put * in .gitignore it repeatedly opens Git for Windws in the background until it maxes CPU and crashed my machine.

[rodneyliu90]

I had this same issue, and worked around it by adding a .gitignore for some large log/csv files that were in my project, and committing the rest of my unstaged changes. I believe this was caused by codex repeatedly trying git add -A which took a long time to process against several 5-10GB files.

[adamgwinn]

I’m seeing what looks like the same Windows git.exe fan-out pattern, with one additional detail that may help narrow the trigger.

Environment:

• Windows 11
• Git for Windows
• Codex Desktop: pre-update package visible in process command line was OpenAI.Codex_26.608.1337.0
• Codex later updated during my test window; I can add the exact post-update version from About Codex if useful.

What I observed:

• Codex spawned many git.exe processes under Codex.exe / codex.exe.

• During the bad state, the distinctive command was:

  git.exe -c core.hooksPath=NUL -c core.fsmonitor= hash-object --no-filters -- <path>

• The workload looked like file-by-file hashing of generated artifacts, especially JSON/HTML/MD/CSV/email-style files under hot output folders.

Diagnostics I collected:

• I wrote a PowerShell watchdog that logs every git.exe process with parent process, grandparent process, command line, classification, path count, and recent hash-object count.
• In the pre-mitigation logs, the bad rows were repeated hash-object --no-filters -- <file> invocations against generated artifacts.
• After mitigation and a later Codex update, a fresh storm-only monitor run from 2026-06-11T17:35:19 to 2026-06-11T18:07:14 logged:
  • total git rows: 1582
  • HashObjectRows: 0
  • StormRows: 0
  • WouldKillStorm: 0
  • normal noise was mostly rev-parse, remote -v, status --porcelain, config core.fsmonitor, diff, ls-files, etc.

Mitigation that appears to have helped:

• Moved future generated outputs into ignored scratch folders like _tmp/<workflow>/<run>/....
• Added narrow .gitignore rules for historical hot generated folders and file types.
• Updated local workflow/agent instructions so future runs do not create high-cardinality generated artifacts in Git-visible batch folders.
• I also switched from a kill-all git.exe watchdog to a storm-only monitor so normal Codex Git probes are allowed and only hash-object fan-out is flagged.

My interpretation:

• My repo hygiene likely amplified the issue by putting many generated artifacts in active workspaces.
• But Codex probably still needs a product-side guardrail here: bounded/debounced/cached Git scans, cancellation, and avoiding per-file Git process storms over generated/ignored artifact directories.
• It would also help to have a supported setting to disable or reduce Codex Git integration/polling on Windows.

I can provide a sanitized CSV excerpt from the watchdog if that would be useful.