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

Activity

1. Snowsword168

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jun 24, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   performance

   on Jun 24, 2026
3. github-actions commented on Jun 24, 2026

   

   github-actionsBot

   on Jun 24, 2026 – with GitHub Actions

   Contributor

   More 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
4. Yassycodes commented on Jun 25, 2026

   

   Yassycodes

   on Jun 25, 2026 – with ChatGPT Codex Connector

   More actions

   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.
5. GuilhermeCouto commented on Jun 25, 2026

   

   GuilhermeCouto

   on Jun 25, 2026

   More actions

   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.
6. niderost commented on Jun 29, 2026

   

   niderost

   on Jun 29, 2026 – with ChatGPT Codex Connector

   More actions

   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.
7. niderost commented on Jun 29, 2026

   

   niderost

   on Jun 29, 2026 – with ChatGPT Codex Connector

   Last edited by niderost

   More actions

   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.
8. crash2kx commented on Jul 1, 2026

   

   crash2kx

   on Jul 1, 2026 – with ChatGPT Codex Connector

   More actions

   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.
9. crash2kx commented on Jul 1, 2026

   

   crash2kx

   on Jul 1, 2026 – with ChatGPT Codex Connector

   More actions

   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: crash2kx@ad24464
   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.
10. keydango27-maker commented on Jul 5, 2026

    

    keydango27-maker

    on Jul 5, 2026 – with ChatGPT Codex Connector

    More actions

    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.
11. Snowsword168 commented on Jul 15, 2026

    

    Snowsword168

    on Jul 15, 2026

    Author

    More actions

    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.
12. suiyuebaobao commented on Jul 22, 2026

    

    suiyuebaobao

    on Jul 22, 2026 – with ChatGPT Codex Connector

    More actions

    The repeated scanning of empty .git directories and downstream Defender CPU here closely match the behavior I reproduced.

    I published a single-file Windows launcher for the original Microsoft Store/MSIX Codex app:

    • Repository: https://github.com/suiyuebaobao/codex-git-refresh-workaround
    • Direct download: https://raw.githubusercontent.com/suiyuebaobao/codex-git-refresh-workaround/main/Codex-Git-Disabled.cmd

    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.
13. 5168413518 commented on Oct 8, 2026

    

    5168413518

    on Oct 8, 2026 – with ChatGPT Codex Connector

    More actions

    Related but distinct trigger: our ancestor .git was not empty/invalid. It had a normal Git directory layout but no commits, index, or remotes. The issue was that nested Codex project folders inherited an unintended Git root at %USERPROFILE%.

    Confirmed Windows 10 workaround: accidental Git repo at %USERPROFILE% was causing idle Codex Git scans

    I reproduced high idle CPU/heat in the Microsoft Store ChatGPT/Codex desktop app 26.1002.7124.0 on Windows 10. No local agent task was running; fully exiting the app reduced the load.

    Evidence before the change

    • The main ChatGPT.exe was launching repeated git.exe subprocesses. One captured command was git ... ls-files --cached -z -- AppData/Local/Packages/....
    • Five distinct short-lived Git PIDs appeared in ~2.5 seconds.
    • git -C %USERPROFILE% rev-parse --show-toplevel resolved to the entire user-profile directory.
    • An unintended %USERPROFILE%\.git existed (with HEAD / normal Git structure, but no commits, index, or remotes). Persisted Codex project directories nested under %USERPROFILE%\.codex\.chatgpt-projects\... thus inherited the profile-level Git root.
    • A separate real development repository on another drive had its own .git and was unaffected.

    Reversible workaround that worked here

    1. Verify whether %USERPROFILE%\.git is actually needed. Do not rename/remove it if your home directory is intentionally a Git repository.
    2. Fully exit ChatGPT/Codex desktop (including background/tray processes).
    3. Back up/rename only that unneeded ancestor repo from %USERPROFILE%\.git to a timestamped .git_backup_YYYY-MM-DD; do not delete it.
    4. Restart the app. Verify the home folder is no longer a Git worktree, then verify each actual development repository still resolves to its own Git root.

    After: 0 git.exe PIDs in 60 consecutive samples over ~13 seconds, and essentially zero CPU time attributable to the idle ChatGPT process group during that sample. The affected laptop's temperature improved. Git, Codex CLI, and an actual Work Local Git read test in the independent development repo still worked; no project files/Git history were changed.

    This is one confirmed local mitigation, not an upstream fix. It does not establish the cause of unrelated taskkill.exe/WMI polling bugs or UI freezes. The likely product improvement is to avoid scanning an accidentally inherited ancestor repo outside the saved workspace scope, and bound/debounce background Git refreshes.

    — Пчеличко (Pchelichko)