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

[Snowsword168]

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

Version 26.616.81150

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 10

What issue are you seeing?

Codex Desktop on Windows appears to create empty folders named .agents, .codex, and .git inside project directories. The empty .git directories are then picked up by Codex Desktop's own background Git origin scanner, which repeatedly launches Git for Windows to run git config --get remote.origin.url. This causes a continuous git.exe / conhost.exe process loop and triggers Microsoft Defender real-time scanning, resulting in sustained high CPU and high power usage.

Deleting the empty .git directories immediately stops the git.exe loop and reduces Defender CPU usage back to low levels without restarting Codex.

What steps can reproduce the bug?

Once empty .git directories exist, Codex Desktop's background git-origins scanner repeatedly launches Git for Windows.

• Microsoft Defender process Antimalware Service Executable rises to around 20% CPU.
• Windows Task Manager shows high or very high power usage.
• Git for Windows and Console Window Host repeatedly appear and disappear.
• Codex may be idle, but the process churn continues.
• Removing the empty hidden directories causes Defender CPU to drop below 2% and stops the git.exe loop.

Evidence from Codex Logs

Codex logs repeatedly show Git origin scanning:

requestKind=git-origins
source=sidebar_workspace_task_groups_task_dirs

What is the expected behavior?

Codex Desktop should not create an empty .git directory unless it is initializing a real Git repository.
If Codex creates placeholder directories, its own Git scanner should ignore empty .git directories that are not valid Git repositories.
Codex should not repeatedly launch Git in the background for directories that have no remote origin and no real Git metadata.

Additional information

The Project feature is a helpful way to separate different topics and workflows. However, Codex should not automatically create empty .git, .agents, or .codex directories as placeholders, especially for projects used in “for everyday work” mode.

[github-actions]

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

• Windows: Opening Codex tab in non-Git workspace causes continuous git.exe spawning and high Defender CPU #29858
• Windows Codex desktop app creates an empty .git folder, then spawns git process repetitively #29492
• VS Code extension sandbox leaves empty .git directory, causing Git discovery CPU spin #28631

Powered by Codex Action

[Yassycodes]

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: #29949 (comment)

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.

[GuilhermeCouto]

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.

[niderost]

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.

[niderost]

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.

[crash2kx]

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.