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

Summary

Codex Desktop on Windows repeatedly launches Git polling commands from Codex.exe in a native Windows multi-repo workspace. In the observed sessions, many git.exe processes remain alive after the polling command should have completed.

This reproduced on two Windows PCs against the same style of workspace. The strongest local capture shows 181 distinct git.exe processes first seen during a 45 second high-frequency polling window; 118 of those had Codex.exe as the direct parent while the parent was still alive.

I am not claiming a repository corruption root cause. Some stale index.lock files were observed on one machine, but another machine reproduced the same git.exe command pattern without lock files.

Environment

Machine A:

Codex Windows app: OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0
Codex app version: 26.616.6631.0
Windows: Windows 11 Pro, version 10.0.26200, build 26200, 64-bit
PowerShell: 5.1.26100.8655
Git: git version 2.52.0.windows.1
Git executable paths observed:
- D:\Program Files\Git\cmd\git.exe
- D:\Program Files\Git\mingw64\bin\git.exe
Workspace shape: native Windows drive, root directory is not itself a Git repo, with multiple child Git repositories.

Machine B:

Same issue pattern reproduced in another native Windows multi-repo workspace.
No child repo had .git/index.lock in that run.
Parent processes had already exited by the time they were queried, so this machine only confirms the command pattern and residue, not the direct parent chain.

Observed commands

The leftover/new git.exe processes use this repeated command family:

git.exe -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelain
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false rev-parse HEAD
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false remote -v
git.exe config --null --get core.fsmonitor
"D:\Program Files\Git\cmd\git.exe" -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel

The rev-parse --show-toplevel command is notable because the captured command line had core.fsmonitor= rather than core.fsmonitor=false.

Direct parent-chain evidence

A high-frequency CIM polling capture on Machine A ran for 45 seconds and wrote these summary values:

{
  "SampleRows": 397,
  "DistinctGitProcesses": 181,
  "FirstSeenWithParentAlive": 178,
  "FirstSeenDirectCodexParents": 118
}

Representative captured parent chain:

ParentName: Codex.exe
ParentCommandLine: "C:\Program Files\WindowsApps\OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0\app\Codex.exe"
Child executable: D:\Program Files\Git\cmd\git.exe
Child command: "D:\Program Files\Git\cmd\git.exe" -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel

Another representative direct child:

ParentName: Codex.exe
ParentCommandLine: "C:\Program Files\WindowsApps\OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0\app\Codex.exe"
Child executable: D:\Program Files\Git\cmd\git.exe
Child command: "D:\Program Files\Git\cmd\git.exe" config --null --get core.fsmonitor

Earlier in the same investigation, after manually terminating confirmed Git polling residue, new git.exe processes reappeared within about 10 seconds and the direct parent was again observed as Codex.exe.

Lock-file observations

On Machine A, after the issue had already been observed, three zero-byte .git/index.lock files were found in sibling child repositories:

<workspace>\repo-a\.git\index.lock  length=0  LastWriteTime=2026-06-22 03:49:45 +08:00
<workspace>\repo-b\.git\index.lock  length=0  LastWriteTime=2026-06-22 02:56:43 +08:00
<workspace>\repo-c\.git\index.lock  length=0  LastWriteTime=2026-06-22 03:49:45 +08:00

The main repo being worked in did not have index.lock. Machine B reproduced the git.exe residue pattern with all child repos reporting no .git/index.lock.

So the lock files may be a consequence or separate symptom, but they are not required to reproduce the repeated Git polling process pattern.

Flutter investigation boundary

This was originally noticed while investigating Windows shell/child-process reliability in a Flutter workspace. I checked whether the observed Git residue directly explains flutter.bat hangs.

Current minimal probe did not prove a Flutter causal link:

Direct Dart invocation of Flutter tools: completed in about 1.0s, no timeout.
flutter.bat --version under a hard-timeout wrapper: completed in about 1.4s, no timeout.
No evidence currently shows Flutter waiting on git.exe, and no claim is made that Git residue causes Flutter hangs.

The confirmed issue in this report is the repeated/stuck Git polling process behavior from Codex Desktop on Windows.

Expected behavior

Codex's Git polling/review functionality should either:

run short Git metadata/status commands and reap them promptly, or
avoid launching overlapping Git polling commands for the same workspace when prior ones have not exited, and
avoid leaving stuck/orphaned git.exe processes or stale .git/index.lock files.

Actual behavior

Codex Desktop repeatedly launches Git polling commands. Many git.exe processes remain alive, and in one 45 second observation window over 100 newly seen Git processes had Codex.exe as direct parent.

Reproduction outline

Open a native Windows multi-repo workspace in Codex Desktop.
Do not run build/test/Flutter commands.
Observe git.exe processes with PowerShell:

Get-CimInstance Win32_Process -Filter "Name = 'git.exe'" |
  Select-Object ProcessId,ParentProcessId,CreationDate,ExecutablePath,CommandLine

For parent chain, poll quickly enough to catch the parent before it exits:

Get-CimInstance Win32_Process |
  Where-Object { $_.Name -in @('Codex.exe','codex.exe','git.exe') } |
  Select-Object ProcessId,ParentProcessId,Name,CreationDate,ExecutablePath,CommandLine

Repeat for 30-60 seconds and count distinct git.exe PIDs and direct Codex.exe parents.

Notes

Register-WmiEvent with Win32_ProcessStartTrace was attempted for stronger process-create evidence but was denied by Windows permissions on this machine, so the strongest machine-readable evidence here is high-frequency CIM polling plus direct parent snapshots.
The issue appears environment/app-level, not repository-specific.

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

Windows 10 app 26.616.4196.0 repeatedly spawns Git root/metadata probes while idle #29110
Codex Desktop (macOS): source-control watcher spawns thousands of git/sec on workspaces containing embedded git repos → syspolicyd/trustd CPU storm, fans max #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:

Windows 10 app 26.616.4196.0 repeatedly spawns Git root/metadata probes while idle #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.
Codex Desktop (macOS): source-control watcher spawns thousands of git/sec on workspaces containing embedded git repos → syspolicyd/trustd CPU storm, fans max #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.
VS Code extension sandbox leaves empty .git directory, causing Git discovery CPU spin #28631 has a similar rev-parse --show-toplevel shape, but is VS Code extension + Linux remote + empty .git sandbox residue.
Codex Desktop review-summary spawns thousands of git hash-object processes when nested repositories are present #27570 / Git worker thread OOM crash (SIGABRT) when workspace contains nested git repos and large directory trees #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 --
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

The repeated or stuck Git polling across a multi-repository workspace here is the same class of Git-backed refresh workload 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.

Navigation Menu

Repository navigation

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

Summary

Environment

Observed commands

Direct parent-chain evidence

Lock-file observations

Flutter investigation boundary

Expected behavior

Actual behavior

Reproduction outline

Notes

This should be treated as blocker severity for Codex Desktop.

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Observed commands

Direct parent-chain evidence

Lock-file observations

Flutter investigation boundary

Expected behavior

Actual behavior

Reproduction outline

Notes

Activity

github-actions commented on Jun 22, 2026

maplel commented on Jun 22, 2026

maplel commented on Jun 22, 2026

VMescheryakov commented on Jun 26, 2026

This should be treated as blocker severity for Codex Desktop.

maplel commented on Jun 27, 2026

maplel commented on Jun 27, 2026

Simonadevy commented on Jun 29, 2026

Luluno01 commented on Jul 1, 2026

maplel commented on Jul 7, 2026

artemrizhov commented on Jul 13, 2026

suiyuebaobao commented on Jul 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions