Codex Desktop Creates Empty `.git` Directories, Then Repeatedly Scans Them and Triggers Windows Defender High CPU

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

• #29858
• #29492
• #28631

Powered by Codex Action

Thanks for writing this up. I am seeing a related Windows Codex Desktop performance regression in #28855: since June 12, opening/using Codex Desktop can cause severe intermittent mouse/typing/system input lag, and it still persists for me on OpenAI.Codex 26.616.10790.0.

I linked your report in a broader Discussion collecting recent Windows Desktop performance reports here: https://github.com/openai/codex/discussions/29949#discussioncomment-17428007

No action needed from you unless you want to add more detail there, but I wanted to connect the reports because the recent Windows issues look related enough that they may need a canonical tracker.

I have the same issue, my Windows Desktop Codex creates a .git folder inside of my project folder(1 level below the project folder with original .git) and bugs my IDE. I need to delete to solve.

I can confirm this is still reproducible for me on the current Windows Codex app, and I have before/after process evidence that an empty/non-repository .git directory is enough to trigger repeated Git child-process spawning.

Environment:

• Codex Windows app package: OpenAI.Codex 26.623.5546.0
• OS: Windows 11 Pro 10.0.26200, 64-bit
• Git: git version 2.54.0.windows.1
• Codex main process in the fresh capture: PID 26416

Trigger condition:

• Project directory contains a .git directory, but it is not a valid Git repo.
• The .git directory was empty: recursive item count 0, no .git/HEAD.
• git -C <project> rev-parse --git-dir --git-common-dir --is-inside-work-tree --show-toplevel returns:

fatal: not a git repository (or any of the parent directories): .git

Observed current behavior:

• With the empty .git directory present, a 30-second process monitor captured 138 Git processes, 94 of them direct children of the Codex main process.
• Direct child command counts included:
• 56 x "C:\Program Files\Git\cmd\git.exe" -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel
• 6 x "C:\Program Files\Git\cmd\git.exe" config --null --get core.fsmonitor
• 32 direct children where command line was gone before it could be read
• Direct child working-directory counts included:
• 51 x the affected project directory
• 43 x blank/unreadable current directory

Mitigation/control:

• I renamed the empty .git directory aside, without restarting Codex.
• An immediate follow-up 30-second monitor captured 0 Git processes.
• The same pattern was captured yesterday on an earlier Codex main process:
• Before renaming empty .git: 60-second monitor captured 128 Git processes, 95 direct children.
• After renaming empty .git: 60-second and 120-second monitors both captured 0 Git processes.

Impact:

• On this workstation the repeated Git process spawning correlated with a sustained hot Codex/libuv thread, background CPU load, fan spin-up, and thermal pressure.
• The symptom can reappear if the empty .git directory is recreated; I saw it recur today after having mitigated it yesterday.

Likely product-side fix:

• Treat .git existence as only a hint, not proof of a valid Git repository.
• If rev-parse --show-toplevel returns "not a git repository" for a directory whose .git path exists but is invalid/empty, do not immediately re-arm a watcher that synchronously re-triggers on the same invalid .git directory.
• Add a negative cache/backoff for invalid .git directories, or require a real Git marker such as .git/HEAD / valid gitfile contents before firing the "git initialized" path.

I have local CSV/JSON captures and stack samples if maintainers want them, but I did not attach raw logs here because they contain local paths/session context.

Follow-up / correction to my earlier follow-up: I want to narrow this to the part I can actually support.

After mitigating the repeated Git-spawning issue by renaming/removing an empty invalid .git, I noticed that the affected workspace was an old Codex workspace path whose real work had since been moved elsewhere. I had deliberately left a local pointer file in the old directory when I moved the work, so that file name is not itself a Codex artifact or meaningful product signal. It is just how I marked my own move. If I had deleted the old workspace entirely, this variant may not have appeared.

The relevant pattern is:

1. A Codex project/thread can remain associated with an old workspace path.
2. The real active work is moved elsewhere.
3. The old path remains as a non-git placeholder directory.
4. An empty/invalid .git may appear or reappear there.
5. Git metadata discovery then repeatedly probes that stale invalid repo path, causing repeated git.exe work as described in my previous comment.

I am intentionally omitting exact local path names and my own cleanup/workaround artifacts here; those are not product signals.

The product-side checks that still seem useful:

• do not treat .git existence alone as proof of a valid repository; require a valid .git/HEAD, a valid gitfile, or a successful rev-parse;
• negative-cache invalid .git directories and non-git workspaces with backoff;
• if persisted project/sidebar/thread state points at a stale/non-git workspace, avoid continuous background Git metadata work against it;
• if a workspace has moved or been deleted, clean up or mark the persisted workspace path inactive until explicitly reopened.

This may still relate to the other reports about stale project state and empty .git creation, but the actionable signal from my side is narrower: stale workspace path + invalid empty .git + repeated Git probing.

I can confirm this pattern on Windows with Codex package OpenAI.Codex_26.623.11225.0.

A current Codex chat workspace contained an empty/invalid .git directory:

%USERPROFILE%\Documents\Codex\2026-07-01\shutdown-windows-the-laptop-is-running\.git

The directory was empty and had no HEAD, no config, and no objects.

While Codex was idle, ETW showed repeated child processes from Codex.exe:

git.exe -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel
git.exe config --null --get core.fsmonitor

Before removing the empty .git directory, a 120s sample saw:

• 115 new git.exe processes
• 96 new conhost.exe processes
• MsMpEng.exe at ~55.6% of one CPU core

After deleting only that empty .git directory, a 60s sample saw:

• 0 new git.exe processes
• 0 new conhost.exe processes
• MsMpEng.exe at ~1.1% of one CPU core

So in this case Microsoft Defender was not the root cause. It was amplifying Codex's repeated Git probing against an invalid empty .git directory.

One extra detail: this was not a real user Git repository. It was the current default Codex workspace/chat folder under %USERPROFILE%\Documents\Codex\..., and the invalid .git directory was empty.

Follow-up: I prepared a candidate fix in a fork, but I cannot open a PR because this repository currently restricts PR creation to collaborators.

Branch: https://github.com/crash2kx/codex/tree/codex/ignore-invalid-dot-git
Commit: https://github.com/crash2kx/codex/commit/ad2446498983a574b728599d01c0b5ba02fdb28c
Compare: https://github.com/openai/codex/compare/main...crash2kx:codex/ignore-invalid-dot-git

The patch changes lightweight Git root discovery so an empty .git directory is not treated as a valid repository marker. .git directories now need the minimal structure Git itself accepts (HEAD, objects/, refs/), while .git pointer files using gitdir: remain supported. I also added regression coverage for empty .git directories.

Local validation performed:

• git diff --check
• Manual git rev-parse --is-inside-work-tree probe confirmed HEAD + objects + refs is accepted by Git while empty/HEAD-only .git directories are rejected.

cargo test was not run locally because the Windows host used for this fix does not have a Rust toolchain installed and WSL is not installed.

Another confirmed Windows data point for the invalid/empty .git trigger, with one additional mitigation detail.

In my case the high idle CPU/power issue remained after several Codex updates and initially looked like generic desktop idle load. Further tracing showed Codex repeatedly launching this command family from a persisted workspace path:

git.exe -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel

The affected workspace path contained an empty/invalid .git directory. I am intentionally omitting the real local path and any user-specific names here.

What finally fixed it locally:

1. Back up / rename the invalid empty .git directory.
2. If that workspace path is stale and not needed, removing the invalid .git is enough.
3. If Codex/project state still points at that workspace and the path needs to remain stable, creating a minimal valid Git repo also works.
4. For that minimal repo, reduce scan cost with:

git config core.untrackedCache true
git config status.showUntrackedFiles no

and put this in .git/info/exclude:

/*

Verification after fixing the invalid .git:

• repeated Codex-launched git.exe probes stopped (git_count=0 during follow-up sampling);
• before the fix, nonpaged-pool/file-cache related counters were still climbing over a few minutes;
• after the fix, the same counters were effectively flat over the follow-up window;
• the visible idle CPU/package-power symptom disappeared.

So this matches the product-side diagnosis already discussed here: Codex should not treat .git existence alone as a valid repository signal. A valid .git/HEAD / gitfile / successful rev-parse check, plus negative caching/backoff for invalid .git directories, would likely prevent this loop.

I published a conservative temporary Windows workaround for the empty/invalid .git trigger discussed here:

https://github.com/Snowsword168/CodexGitGuard

It is event-driven, removes only persistently empty child .git directories, preserves non-empty repositories and worktree pointer files, and does not terminate processes. It is not an official OpenAI fix and is intended only as a mitigation until the underlying repository-detection loop is fixed.