Windows Desktop leaves repeated/stuck git.exe polling processes in multi-repo workspace

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

• #29110
• #29084

Powered by Codex Action

Additional cross-machine evidence from a second Windows PC, with repository/workspace names intentionally omitted:

Environment:

• Codex Desktop: OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0
• Codex version: 26.616.6631.0
• Install path: C:\Program Files\WindowsApps\OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0
• Git: git version 2.54.0.windows.1
• PowerShell: 5.1.22621.4391
• Windows: Microsoft Windows 11 Pro, 10.0.22631, build 22631, 64-bit

Workspace/index-lock state:

• Multi-repo workspace with six sibling Git repositories.
• All six repositories had IndexLockExists=false before/during capture.
• No Flutter, Gradle, build, test, push, pull, fetch, branch, merge, or commit commands were run during this read-only capture.
• No processes were killed and no lock files were deleted.

Codex processes on this machine:

PID 33760, Parent 27232, Codex.exe
"C:\Program Files\WindowsApps\OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0\app\Codex.exe"

PID 9028, Parent 33760, codex.exe
"...\app\resources\codex.exe" app-server --analytics-default-enabled

45-second read-only polling sample:

SampleStart: 2026-06-22 15:10:25.1272128 +08:00
SampleEnd:   2026-06-22 15:11:10.1437584 +08:00
ActualDurationSeconds: 45.017
SampleCount: 113
Distinct git.exe: 159
Parent alive at first observed: 155
Direct parent Codex.exe/codex.exe at first observed: 101
Any .git/index.lock: false

Representative git.exe records:

PID 11576, Parent 34948, Created 2026-06-22 15:09:47.7481030 +08:00
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false rev-parse HEAD

PID 9112, Parent 40468, Created 2026-06-22 15:09:47.7504680 +08:00
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false remote -v

PID 29472, Parent 29612, Created 2026-06-22 15:09:47.7528190 +08:00
git.exe config --null --get core.fsmonitor

PID 21220, Parent 4860, Created 2026-06-22 15:09:52.7597560 +08:00
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelain

PID 18976, Parent 33760, Created 2026-06-22 15:11:08.9865420 +08:00
"C:\Program Files\Git\cmd\git.exe" -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel
ParentName: Codex.exe
ParentCommandLine: "...\app\Codex.exe"

Residual snapshot after sampling:

Snapshot 2026-06-22 15:11:48 +08:00

PID 11576, Parent 34948, rev-parse HEAD
PID 9112,  Parent 40468, remote -v
PID 29472, Parent 29612, config --null --get core.fsmonitor
PID 21220, Parent 4860,  status --porcelain
PID 9492,  Parent 33760, CommandLine=null, ParentName=Codex.exe
PID 19972, Parent 9492,  CommandLine=null

Interpretation from this second machine:

• This reproduces the same behavior on a different Windows build and a different Git for Windows version.
• It also reproduces with no .git/index.lock files, so stale index locks are not a required precondition.
• The command pattern is the same as on the first machine.
• The direct-parent evidence is now reproduced cross-machine: 101 newly observed git.exe processes had direct parent Codex.exe/codex.exe during the 45-second sample.

This strengthens the hypothesis that the issue is in Codex Desktop Windows Git metadata/status polling process cleanup, rather than repository-specific state, one Git version, one Windows build, or stale index locks as a required trigger.

Follow-up after reviewing the duplicate suggestions from the bot:

I reviewed #29110 and #29084, plus their linked chain (#28631, #27570, #27382). My current read:

• #29110 is the closest prior report: Windows Desktop, idle/repeated Git metadata probes, and the same command family (rev-parse --show-toplevel, config --null --get core.fsmonitor, remote -v, status --porcelain). However, it was closed by its reporter as caused by an orphaned/broken .git folder inside .codex. This issue is not currently filed as that root cause: it has cross-machine Windows evidence, including one machine with no .git/index.lock in the child repos, and direct parent-chain captures showing Codex.exe launching git.exe.
• #29084 appears related at the source-control watcher / unbounded Git polling layer, but that report is macOS-specific, nested/embedded-repo triggered, and expresses as high spawn rate / syspolicyd/trustd CPU, not Windows residual/stuck git.exe processes.
• #28631 has a similar rev-parse --show-toplevel shape, but is VS Code extension + Linux remote + empty .git sandbox residue.
• #27570 / #27382 are broader Git-worker fanout/OOM issues around nested repos / review-summary, not the same idle Windows metadata polling command family.

So this may be in the same Git worker / SCM watcher problem family, with #29110 as the nearest neighbor, but I do not think there is enough evidence to close this as a duplicate yet.

This should be treated as blocker severity for Codex Desktop.

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 process and the files it touches can be inspected by Defender or 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.

Observed command on Windows:

"C:\Program Files\Git\cmd\git.exe" -c attr.tree= -c core.attributesFile= -c filter.lfs.clean= -c filter.lfs.smudge= -c filter.lfs.process= -c filter.lfs.required=false -c core.hooksPath=NUL -c core.fsmonitor= status --porcelain=v1 -z

Parent process: Codex.exe.

Impact:

• Git workspaces become practically unusable in Codex Desktop.
• The app burns CPU and disk I/O while idle.
• Fans spin up and battery drains.
• AV/Gatekeeper amplification makes the issue appear as OS/security-process load rather than Codex load.
• The workaround “do not open a Git repo” defeats the core use case of a coding agent.
• .gitignore hygiene helps only some cases; it does not fix continuous background process spawning.
• Excluding workspaces or git.exe from antivirus is not acceptable in managed/corporate environments.

This is not merely a Git performance issue. Codex is converting idle UI state refresh into repeated trusted-executable launches and whole-worktree security scans.

Expected behavior:

Codex should not poll Git continuously in the background. It should run Git only on explicit user actions or task boundaries, or provide a setting to disable background SCM polling. If background refresh is retained, it needs strict debounce/backoff, single-flight execution, no nested repo traversal, timeout cleanup, and no parallel Git process accumulation.

Severity: Blocker / P0-P1, because the app’s primary target workload is Git repositories, and affected users cannot safely or comfortably keep Codex Desktop open on real projects.

Maintainer triage request:

This is still blocking real Codex Desktop use for us after several days. Could a maintainer please triage this as Blocker / P0-P1, assign an owner, or state what additional signal is needed?

Why I believe this is above ordinary performance severity:

• It affects the primary Codex Desktop workflow: keeping real Git workspaces open.
• It reproduces across multiple Windows PCs and Git versions.
• It does not require Flutter/Gradle/build/test commands.
• It does not require stale .git/index.lock files.
• In 45-second read-only samples, we observed 181 / 159 distinct git.exe processes, with 118 / 101 direct Codex.exe or codex.exe parents.
• The workaround is effectively “do not keep Codex Desktop open on real Git workspaces,” which defeats the core product use case.
• AV/Defender amplification makes this risky in managed/corporate Windows environments; excluding git.exe or workspaces from AV is not an acceptable mitigation.

Requested next step:

Please confirm whether this is being tracked internally, whether it maps to the broader Git worker / SCM watcher issue family, and whether a short-term mitigation can be shipped, such as:

• a setting to disable background SCM polling,
• strict single-flight Git polling per workspace,
• debounce/backoff,
• hard timeout and process cleanup,
• no nested repo traversal unless explicitly enabled.

If P0 is not appropriate, please say what evidence would move this from performance bug to a release-blocking Windows Desktop issue.

Additional routing signal: I also submitted this through Codex Desktop's Send feedback channel.

Feedback ID: 019f0b42-653b-76e2-99f8-68a6828c9305

Posting the ID here so the internal feedback record can be correlated with this public GitHub issue and the reproduction/evidence already attached above.

I am seeing what looks like the same issue.

Feedback/log bundle ID: 019f09ca-366a-7b40-8429-d5db4bdbb987

Environment:

• Windows Codex app
• Codex app was spawning many git.exe processes repeatedly
• I am actively working in multiple local Git repositories
• Repositories are local; no GitHub/origin workflow is involved

I disabled these settings/features:
[features]
undo = false
codex_git_commit = false
shell_snapshot = false

I also disabled PR drafts and worktree auto-cleanup in the app settings.

Despite restarting Codex, Codex.exe continues to spawn git.exe children repeatedly.

Observed process tree:
Codex.exe -> git.exe

Commands observed:
git add -u
git add -- <files>
git status --porcelain=v1 -z
git ls-files --others --exclude-standard -z
git config --null --get core.fsmonitor
git diff --no-ext-diff --no-textconv --find-renames --name-status -z
git diff --no-ext-diff --no-textconv --find-renames --numstat -z
git diff --no-ext-diff --no-textconv --find-renames --raw -z

The commands include:
-c core.hooksPath=NUL
-c core.fsmonitor=

So it does not appear to be caused by my Git hooks or fsmonitor.

Impact:

• Sustained CPU usage and fan noise
• Killing the git.exe processes does not help; Codex.exe immediately recreates them
• I cannot mark the projects as untrusted because I am actively working in those local repos

Expected:
A setting to disable background Git/review/diff/snapshot polling, or a fix so these Git operations are throttled and only run when needed.

I’m seeing what appears to be the same Git subprocess churn pattern on a newer Windows Codex build, with an additional downstream symptom: most of the visible CPU is sometimes charged to Windows PcaSvc / Program Compatibility Assistant Service rather than to Codex.exe or git.exe directly.

Environment:

• Windows native Codex Desktop, not WSL backend
• Codex package: OpenAI.Codex_26.623.11225.0_x64__2p2nqsd0c76g0
• Workspace cwd: <workspace>
• Git path observed: D:\Program Files\Git\cmd\git.exe
• Parent chain confirmed locally: powershell.exe <- codex.exe app-server <- Codex.exe <- explorer.exe

Observed behavior:

When Codex is open, Task Manager total CPU rises. The processes at the top are often not Codex itself, but Windows services such as:

• Service Host: Program Compatibility Assistant Service
• Antimalware Service Executable
• occasionally WMI Provider Host

Closing Codex drops the total CPU noticeably.

I captured native Windows counters and ProcMon traces. The strongest evidence so far:

• PcaSvc was hosted by svchost.exe PID 13100
• typeperf over 120s showed PcaSvc peaking at about 95.8% of one logical core, averaging about 22.8%
• MsMpEng.exe also spiked, but lower: peak about 57%, average about 5.9%
• Codex’s own process CPU was much lower in that sample: peak about 7.7%, average about 0.2%

ProcMon evidence from a 30s capture:

• PcaSvc generated 409,206 events in 30s
• Top operations were mostly registry/file/AppCompat activity:
• RegOpenKey: 120,557
• RegCloseKey: 71,790
• RegQueryValue: 55,074
• RegQueryKey: 49,200
• CreateFile: 22,411
• Hot paths included:
• D:\Program Files\Git\cmd\git.exe
• D:\Program Files\Git\mingw64\bin\git.exe
• C:\Windows\appcompat\Programs\Amcache.hve
• C:\Windows\appcompat\pca\PcaGeneralDb0.txt
• HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags

Most importantly, ProcMon showed Codex repeatedly creating Git processes. One representative event:

Process: Codex.exe
Operation: Process Create
Path: D:\Program Files\Git\cmd\git.exe
Command line:
"D:\Program Files\Git\cmd\git.exe" -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel
Current directory:
<workspace>

git.exe then starts:

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

In the same 30s ProcMon CSV, I counted 946 Process Create events for D:\Program Files\Git\cmd\git.exe.

So my current read is:

• The upstream trigger matches this issue: Codex Desktop repeatedly spawns Git metadata/root-detection commands.
• On my machine, a large part of the resulting CPU is externalized into Windows AppCompat/PCA and Defender, so Task Manager can make the hot processes look “unrelated” to Codex.
• This may explain reports where users see PcaSvc, Defender, WMI, or general system CPU instead of high Codex.exe CPU.

This also seems related to #20567, but this issue has the closest exact command match because of:

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

The actionable fix likely needs to be in Codex’s Git polling/root-discovery path: cache/debounce these probes, avoid overlapping Git subprocesses, and avoid repeatedly spawning Git for the same workspace when the result should be stable.

Could a maintainer confirm whether #30235 or #30863 is intended to address this issue?

From the PR descriptions, they appear to cover adjacent Git status safety/timeout paths, but not the Windows Desktop root-discovery / background polling loop reported here, especially repeated:

• rev-parse --show-toplevel
• config --null --get core.fsmonitor
• status --porcelain / status --porcelain=v1 -z
• diff / ls-files / git add background commands

This issue now has multiple Windows Desktop reproductions, newer Codex builds, feedback/log bundle IDs, and evidence that CPU can be externalized into PcaSvc / Defender, making the source look unrelated in Task Manager.

If this is tracked internally, please link or summarize the tracking status. If not, could it be assigned an owner or marked as a release-blocking Windows Desktop issue?

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