›_ Codex Issues
Codex Issues / #29110

Windows 10 app 26.616.4196.0 repeatedly spawns Git root/metadata probes while idle

Open 💬 7 comments Opened Jun 19, 2026 by privacyguy123
💡 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?

OpenAI.Codex_26.616.4196.0_x64__2p2nqsd0c76g0

What platform are you using?

Windows 10 x64

Git for Windows:

git version 2.54.0.windows.1

What issue are you seeing?

With a local Git workspace open in the Codex Windows app, git.exe repeatedly appears in Sysinternals Process Explorer even when I have not explicitly asked Codex to run a Git command.

One repeatedly observed command is:

"C:\Program Files\Git\bin\git.exe" -c core.hooksPath=NUL -c core.fsmonitor=false rev-parse --show-toplevel

Other Git metadata commands observed in the same app session include:

git.exe config --null --get core.fsmonitor
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false remote -v
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelain

I can provide a Process Explorer screenshot if useful. core.fsmonitor=false appears intentional; the problem is the repeated process creation, not that configuration override.

Why this may be distinct from existing reports

This resembles existing Windows issues, but the visible loop here is centered on root discovery and metadata refresh rather than the older snapshot/index commands:

  • #17229: repeated status --porcelain and orphaned Git/conhost processes
  • #20567: very high Git process creation rate
  • #20933: add -A / Git snapshot work when opening a project
  • #23207: startup git-origins worker fan-out, including rev-parse --show-toplevel
  • #26812: excessive Git/conhost creation in Git workspaces

The source path documented in #23207 identifies rev-parse --show-toplevel as part of the desktop git-origins worker. Current app-server source also creates Git enrichment per turn, concurrently collecting HEAD, remotes, and working-tree status. The status path probes core.fsmonitor for each metadata collection:

This suggests that a workspace/turn-metadata invalidation may be continuously retriggering one or both Git metadata paths. That is a hypothesis, not a confirmed root cause.

Steps to reproduce

  1. Start Codex Windows App 26.616.4196.0.
  2. Open or select a local Git repository workspace.
  3. Leave the project open without manually running Git commands.
  4. Open Sysinternals Process Explorer and filter for git.exe.
  5. Observe repeated short-lived git.exe processes, including rev-parse --show-toplevel.

Expected behavior

Repository root and metadata should be cached, debounced, or refreshed only after a relevant workspace/Git-state event. An idle Codex project should not continuously create Git processes.

Actual behavior

Git metadata probes continue to be spawned repeatedly while the project is idle.

Suggested diagnostics / fix direction

Please add structured logging or counters containing:

  • refresh reason / invalidating event
  • workspace path hash
  • Git command category
  • whether an identical metadata request is already in flight

Then ensure that git-origins and turn-metadata enrichment are debounced and deduplicated per workspace, with no repeated refresh without a relevant state change.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 1 month ago

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

  • #29084
  • #28631

Powered by Codex Action

privacyguy123 · 1 month ago

Caused by orphaned/broken .git folder being in .codex folder.

privacyguy123 · 21 days ago

Bug is back in new build downloaded today - the "fix" I said worked before isn't applicable anymore, there is no orphaned .git folder in .codex anymore.

zhanghaonj-prog · 8 days ago

I can reproduce this on a newer Codex Desktop build, and in my case the workspace did not contain an invalid or empty .git directory.

Environment

  • Codex Desktop: OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
  • OS: Windows 11 Pro 25H2, build 26200.8524
  • Git for Windows: C:\Program Files\Git\cmd\git.exe

Reproduction and measurements

With a task bound to a normal directory that was not inside any Git repository, the Codex Electron main process repeatedly launched:

"C:\Program Files\Git\cmd\git.exe" -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel

Each invocation correctly failed with:

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

A process monitor captured 20 top-level Git processes launched directly by ChatGPT.exe in 7.1 seconds, equivalent to approximately 169.1 launches per minute. Retry intervals were generally between 0.2 and 2.3 seconds. The parent was the Electron main process, not a renderer, GPU, or network-service process.

The loop may be temporarily absent immediately after restarting Codex, then reappear following a workspace refresh or file change. This suggests that the failed repository-root lookup is being retriggered by workspace/filesystem invalidation rather than running only as a fixed startup timer.

Controlled comparison

I ran git init in the exact same working directory without staging or committing any existing files.

After the directory became a valid repository:

  • the repeated failing rev-parse --show-toplevel calls stopped immediately;
  • Git activity fell from approximately 169/minute to 4–6/minute;
  • more than 10 minutes of monitoring showed no recurrence of the high-frequency loop;
  • the remaining calls were associated with real file changes, for example ls-files against a continuously updated log file.

This strongly suggests that a negative result from repository-root discovery is not being cached/debounced, and is repeatedly invalidated for non-Git workspaces.

Performance impact

During the active loop, battery discharge reached approximately 36.71 W. WPR/WPA analysis also showed increased Microsoft Defender activity (WdFilter.sys / MsMpEng.exe) associated with the repeated process and filesystem activity. The loop correlated with occasional UI/mouse stuttering.

I captured a pre-workaround WPR GeneralProfile + FileIO trace (approximately 1.8 GB) and can provide it if there is a secure upload location or if a smaller targeted trace is preferred.

Suggested fix: cache the negative non-repository result and only invalidate it when the workspace path, a relevant parent path, or .git state actually changes. Repeated failures should also be deduplicated and use retry backoff.

zhanghaonj-prog · 8 days ago

Additional diagnostic reference: I submitted this through the Codex Desktop in-app feedback flow with the relevant conversation logs included.

Shared session ID: 019f54cf-377e-7d42-b4d1-e7fd62b234d6

This is the original session in which the high-frequency Git process creation, power impact, WPR trace, and before/after git init comparison were investigated.

artemrizhov · 7 days ago

Same problem with ChatGPT Codex for Windows on directory without .git.
Version 26.707.62119

rwang23 · 6 days ago

I maintain an open-source, reversible Windows workaround for the visible Git/conhost window side of this problem:

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

It uses process-local Git/PowerShell/CMD wrappers and, for MSIX activation paths that bypass that local PATH, a narrowly scoped native guard. The guard hides only a ConsoleWindowClass window whose ancestry contains Git plus either current ChatGPT.exe or legacy Codex.exe.

Safety boundaries are intentional: it does not replace the installed Git executable, change persistent user/system PATH, touch the registry, or hide unrelated terminals.

Important limitation: this reduces the visible-window impact only. It does not reduce the underlying rev-parse/Git polling rate, prevent an orphaned Git process, or resolve the CPU/memory cost reported here. The upstream debounce, cancellation, and no-window process-launch fixes are still needed.

The README is portable (no machine-specific clone path), includes install/rollback steps for users and agents, and documents the trade-offs of the optional PowerShell mitigations. I will keep the workaround updated as Windows desktop package behavior changes; package-version reports with redacted status output are welcome.