Windows desktop app triggers multiple git.exe add -A processes when opening a project/chat, causing severe CPU and disk usage

same

<img width="581" height="539" alt="Image" src="https://github.com/user-attachments/assets/b142a771-bc3a-485a-a4f1-00dee8e9842a" />

<img width="1353" height="813" alt="Image" src="https://github.com/user-attachments/assets/7bd9070e-9145-46ba-90ad-8db5a3f75ae2" />
same, 96gb ram

Same here. WTH is going on? Looks like Git is set out to starve the host of its resources!!

<img width="987" height="707" alt="Image" src="https://github.com/user-attachments/assets/d9a29877-d70c-4787-a459-25e67e0a7e74" />

Follow-up after debugging this further:

I was able to identify a concrete trigger/amplifier. The workspace Git root had a large number of visible, unignored local/generated artifacts: logs, deploy/package output, browser test output, temp folders, server/config snapshots, etc. In this state, git status --porcelain --untracked-files=all showed roughly 20k untracked paths.

While the CPU spike was happening, process inspection showed many concurrent:

git.exe add -A

Codex Desktop logs also showed repeated entries for the same command, with sources including:

• source=local_conversation_git_summary
• source=commit_modal
• requestKind=review-summary
• failureReason=aborted
• very large stderr output before abort

So the pattern seems to be:

1. Codex starts git add -A for review/summary-related Git state.
2. The command is expensive because the repo has many untracked, unignored paths.
3. The command is aborted or fails.
4. Codex starts more git add -A attempts, including overlapping/concurrent ones.
5. The system ends up with many Git for Windows processes consuming CPU.

Workaround that stopped the runaway behavior:

I added local-only Git excludes in .git/info/exclude for the generated/log/temp/deploy/snapshot folders. After that, the visible Git change set dropped from ~20k paths to only the real modified source files, and the repeated git.exe add -A processes stopped.

This workaround avoids exposing or committing local ignore rules, but it also points to the underlying issue: passive summary/review UI flows should probably not run a mutating/index-writing command like git add -A, especially not concurrently or with retry behavior.

Possible app-side mitigations:

• avoid git add -A for passive project/chat/review summaries
• use non-mutating commands such as git status --porcelain, git diff --name-only, etc.
• debounce/cancel previous Git summary jobs before starting another
• enforce a per-repo single-flight guard for Git operations
• cap stderr/stdout collection and stop retry loops after aborts
• consider ignoring untracked files or using --untracked-files=no for lightweight summaries

Additional reproduction / impact report from another Windows Desktop user.

Environment:

• Codex Desktop: 26.506.3741.0
• OS: Windows 11 x64
• Machine RAM: 32 GB
• Repository: large local Git repo, production workspace, many historical/untracked files before mitigation

Observed on 2026-05-10:

• Opening/using Codex Desktop with the production workspace attached caused 21-35 parallel git.exe processes.
• Commands observed included:
• git.exe add -- <300+ file argument list>
• git.exe add -u
• git.exe write-tree
• Individual git.exe processes reached roughly 1.3-2.4 GB RAM.
• Committed memory approached ~50 GB, causing heavy pagefile use and severe system-wide lag.

Amplifying factor:

• A stale LibreOffice lock file named .~lock.yorontou_update_request.pdf# appeared at the head of the huge git add argument list.
• Removing that file and adding .~lock.* to .gitignore reduced per-process git memory from ~1.3 GB to a few MB.
• However, the number of spawned git.exe processes remained high, so the core fan-out issue persisted.

Mitigation that worked:

• Moved Codex Desktop off the production workspace.
• Created a clean clone with zero untracked files.
• Set Codex Desktop active workspace only to the clean clone.
• After 7m46s / 48 monitoring samples, process counts stayed stable at git=3 / codex=6 with no growth.

This supports the existing hypothesis that the desktop app is triggering heavy snapshot/index Git operations passively, and that large/untracked worktrees amplify the failure mode.

I've run into the exact same issue. Codex compares the repository's current branch with the origin/HEAD branch, so you can fix it temporarily by modifying origin/HEAD with this command:
git remote set-head origin xxx

same

<img width="1028" height="583" alt="Image" src="https://github.com/user-attachments/assets/01658d4a-5e0e-4d05-afe2-ef14ce1f709e" />

I found a related failure later in the same passive review-summary workflow and documented it in #27570:

• https://github.com/openai/codex/issues/27570

The process trace shows Desktop first constructing its temporary index using sequential git add -- <up to 1,024 paths> batches and git write-tree, matching the workflow discussed here.

After the metadata diffs, however, revision calculation attempts a bulk:

git hash-object --no-filters -- <all paths>

Three nested-repository directory entries caused that command to fail. The fallback then retried all 5,042 paths concurrently with one Git process per path and no concurrency bound.

This appears adjacent to the git add fanout reported here rather than an exact duplicate: both are passive review-summary operations amplified by large/untracked worktrees, but #27570 identifies a separate unbounded error fallback after snapshot construction.

Thanks for documenting #27570. This matches the operational risk we saw on Windows as well.

In our case, opening Codex Desktop against a large/dirty production workspace caused severe CPU/disk pressure from many Git processes. We have been able to continue working only by treating this as an unresolved Desktop-side risk and avoiding direct attachment to the production workspace where possible, using smaller/cleaner worktrees and stopping immediately if many git.exe add, git write-tree, or related Git processes appear.

So from our side, this is not fully "resolved" by workflow changes. The workflow mitigates the impact, but the underlying Desktop behavior still looks dangerous for large or untracked-heavy repositories.

#27570 looks especially relevant because it suggests another unbounded fallback path after snapshot/revision calculation fails. That seems adjacent to, and possibly part of the same risk class as, this issue.

I can reproduce the same issue on a much newer Windows build of Codex, and an ETW trace shows an additional WMI-related amplification path that can make the entire machine lag.

Environment

• Codex Windows package: 26.715.2305.0
• Windows: 25H2, build 26200.8875, x64
• Git for Windows: 2.53.0.windows.2

User-visible impact

While Codex Desktop is open, mouse movement and keyboard input become delayed. Task Manager shows sustained CPU usage in:

• Service Host: Windows Management Instrumentation (Winmgmt)
• WMI Provider Host (WmiPrvSE.exe)

After stopping my own diagnostic monitor to rule out observer overhead, Winmgmt and WmiPrvSE still consumed roughly 1.7 and 1.4 logical CPU cores respectively.

ETW evidence

I captured synchronized 15-second traces using:

• Microsoft-Windows-Kernel-Process
• Microsoft-Windows-WMI-Activity

During that 15-second window, the Codex Desktop parent process spawned:

• 142 × git.exe
• 142 × taskkill.exe
• 13 × powershell.exe

The taskkill.exe children alone generated 255 WMI operations, including 126 repeated queries against Win32_Process:

SELECT __PATH, ProcessId, CSName, Caption, SessionId, ThreadCount,
       WorkingSetSize, KernelModeTime, UserModeTime, ParentProcessId
FROM Win32_Process

A representative Git child command was performing a per-file diff under a generated dependency tree:

git ... diff --no-index --raw --numstat -z -- /dev/null .tmp/node_modules/.pnpm/pdf-lib@1.17.1/node_modules/pdf-lib/cjs/api/rotations.js

The process tree and WMI client attribution were:

Codex Desktop
  ├─ git.exe       (high-frequency per-file Git work)
  ├─ taskkill.exe  (high-frequency process cleanup)
  │    └─ WMI Win32_Process queries
  └─ powershell.exe
       ↓
Winmgmt / WmiPrvSE high CPU
       ↓
system-wide mouse and keyboard lag

This appears to be the same Git/workspace scanning family described in this issue, with Windows process cleanup through taskkill.exe amplifying the load through WMI.

Large generated/untracked dependency directories such as node_modules appear to amplify the issue, but Codex spawning hundreds of Git and process-cleanup subprocesses within seconds seems to be the underlying problem.

I can provide a sanitized ETW summary if maintainers need more detail. Please investigate throttling/batching repository scans and avoiding a subprocess-per-file / cleanup retry loop on Windows.