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

Open 💬 12 comments Opened May 1, 2026 by msg7086

💡 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)?

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_

View original on GitHub ↗

12 Comments

github-actions[bot] contributor · 2 months ago

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

#19588
#19201
#19568
#19115

Powered by Codex Action

msg7086 · 2 months ago

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 · 2 months ago

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

msg7086 · 2 months ago

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 · 2 months ago

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 · 2 months ago

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

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.

rwang23 · 1 month ago

I maintain a small workaround repo for one part of this Windows Git problem: visible/flashing git.exe console windows when Codex launches Git from the desktop app.

Repo: https://github.com/rwang23/codex-windows-console-guard

Important scope caveat: it does not reduce the number of Git commands Codex runs, so it is not a fix for CPU load, hash-object storms, or large generated-artifact scans. Repo hygiene / .gitignore rules are still the right mitigation for those parts of this issue.

What it can help with is the UX/security-confidence symptom where Git for Windows console windows flash repeatedly. The latest version prefers a native C++ GUI wrapper when a compiler is available, falls back to a managed wrapper otherwise, and keeps everything process-local to Codex without replacing the user's real Git or modifying persistent PATH.

Upstream, Codex still needs bounded/debounced Git scanning and hidden/no-window subprocess launch semantics on Windows.

adamgwinn · 1 month ago

Adding a post-update data point that may be related, but with a slightly different command shape.

Environment:

Windows 11
Codex Desktop process path after update: OpenAI.Codex_26.611.7849.0_x64__2p2nqsd0c76g0

I noticed the recent 0.140.0 release notes / #26880 mention Git/worktree responsiveness and preserving Git fsmonitor. That may help part of this issue, but I can still reproduce a Git process storm after that update.

Trigger context:

Branch/worktree cleanup in a repo with large generated/untracked artifact directories.
Switching branches exposed generated artifact folders that were no longer protected by the branch’s .gitignore.

Distinctive bad command:
git.exe -c core.hooksPath=NUL -c core.fsmonitor= hash-object --no-filters -- <generated-output-path>/...

Watchdog evidence from 2026-06-16:

StormHashObject: 72
hash-object: 72
The rows were file-by-file probes against generated artifact paths.

Local mitigation:

Added branch-independent excludes in .git/info/exclude for the generated artifact directories.
After restarting Codex and running an emergency watchdog, a fresh run showed:
hash-object: 0
StormHashObject: 0
The emergency watchdog still had to kill normal Codex Git probes temporarily while Codex settled.

My hypothesis:

The fsmonitor/worktree-read fix may reduce normal status / diff / ls-files cost.
But Codex can still enter a per-file hash-object --no-filters fan-out when large generated/untracked artifact dirs become visible during branch/worktree operations.

I can provide a sanitized watchdog CSV excerpt if useful. I’m avoiding raw logs because local paths include private project/customer names.

SudoJacky · 1 month ago

I did a simple test, and I think the problem is that the project has a .git folder, but doesn't have a .gitignore file, or it doesn't exclude folders that we usually exclude, such as node_modules/.
This causes the Codex app to traverse folders like node_modules/ when trying to track modified files, potentially crashing your computer. 😀

VMescheryakov · 24 days ago

This should be treated as blocker severity for Codex Desktop.

Reason:
Codex Desktop is a coding agent whose primary workflow is opening Git workspaces. In affected workspaces, the app continuously spawns git.exe / git processes in the background while idle. On Windows, every spawned git.exe and the files it touches are inspected by Defender/corporate AV; on macOS, each git spawn can trigger Gatekeeper/code-signature checks via syspolicyd/trustd. This turns a background SCM watcher into a system-wide CPU/I/O storm.

vesalbehrouzi · 11 hours ago

I can corroborate this issue on a newer Codex Desktop build, and the impact extends beyond CPU usage into Windows kernel security-token pool growth (consistent with #30926).

Environment

Windows 11 Enterprise x64, build 26200
Codex Desktop package: OpenAI.Codex_26.715.7063.0_x64__2p2nqsd0c76g0
Git for Windows 2.35.1
Fresh reboot immediately before the controlled recording
GitLens was disabled for the entire recording

10-minute process trace

Total process starts/stops: 12,399 / 12,121
git.exe starts/stops: 4,038 / 4,017
Codex Desktop's main GUI process (binary name ChatGPT.exe) directly launched:
1,570 git.exe processes
1,565 taskkill.exe processes
Other direct Git parents:
VS Code: 268
Visual Studio: 134
codex.exe: 37
18 Git processes remained at the trace endpoint with parents that had already exited; they eventually cleared several minutes later.

The nearly one-for-one git.exe / taskkill.exe activity looks like a repeated command-abort/cleanup cycle. Observed commands rotated among status --porcelain, remote -v, rev-parse HEAD, rev-parse --git-dir, and config --null --get core.fsmonitor, with Codex's core.hooksPath=NUL / disabled-fsmonitor arguments.

A separate inspection of Codex Desktop logs from the same machine found 291 Git command completions: 279 were source=review_model requestKind=review-summary; 216 were abortedBeforeStart, 66 were aborted, and the longest observed command lasted 24,092 ms.

GitLens / VS Code control

GitLens was definitely inactive:

GitLens activation lines: 0
GitLens Git commands: 0
GitLens log files created: 0

VS Code's built-in Git integration logged 231 commands. This rules out GitLens as the cause and attributes the much larger burst to Codex Desktop.

Windows kernel impact

Exact PoolMon comparison over the same 10 minutes:

Toke outstanding: 5,081 -> 7,800 (+2,719)
Toke bytes: 9,251,392 -> 14,240,384 (+4,988,992 bytes)
Aggregate security-manager tags (Toke, SeAt, SeTd, SeTl, SeDt): +6,990,400 bytes

There was also substantial live-process growth during this workload (295 -> 539 processes; 149,712 -> 260,828 handles), and Toke correlated strongly with live process count (r=0.942). Therefore, not every allocation retained during this short interval is necessarily a permanent leak.

However, before reboot, after 10.24 days of uptime, this system had reached approximately 3.6 million outstanding Toke allocations / 6.23 GiB. Reboot reset it to 4,933 allocations / 8.56 MiB. That multi-gigabyte long-uptime retention is clearly abnormal and is consistent with sustained process churn exercising the Windows process-token duplication path described in #30926.

No third-party driver pool tag was implicated; the accumulating tags map to the Windows Security Manager (nt!se). Codex appears to be the user-mode trigger rather than the kernel allocator itself.

I have retained the raw process-event and PoolMon evidence locally and can provide sanitized CSV summaries if maintainers need them.