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.

The repeated background git add -A workload here is another Git-backed entry point that this workaround intentionally blocks.

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.

I can confirm this is still reproducible after updating Codex Desktop. Feedback ID 019f8777-e2e2-7622-b4eb-7c66257a9caf

Environment

• Codex Desktop: 26.715.10079.0 (updated from 26.715.8383.0)
• Windows 11 x64: 10.0.26200.8875
• Shell: PowerShell
• Workspace: a Unity Git repository
• Observed: July 22, 2026

Post-update behavior

After the update and app restart, the high-CPU state returned within minutes while this task was open. Closing Codex still makes the WMI CPU usage stop.

In a five-sample typeperf capture, one WmiPrvSE.exe instance used approximately 1208% to 1434% Process CPU (about 12 to 14 logical CPU cores).

At the same time, a live process snapshot showed:

• 14 powershell.exe
• 14 taskkill.exe
• 9 git.exe

A follow-up snapshot showed 19 taskkill.exe, 9 powershell.exe, and 4 git.exe, so the process fan-out was still active and changing after the update.

The WMI Activity Operational log recorded 101 event 5858 failures in a ten-minute window, including:

• 33 CreateInstanceEnum root\\cimv2:Win32_Process
• 3 CreateInstanceEnum root\\cimv2:Win32_PerfFormattedData_PerfProc_Process

During the same failure mode before the update, I captured multiple Codex Desktop child processes running this command concurrently:

powershell.exe -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId | ConvertTo-Json -Depth 2"

I also captured many Codex Desktop child processes running:

taskkill.exe /pid <pid> /t /f

The dedicated Codex Git log from that session contained 106 git.command.complete records in about 18 minutes. Of those:

• 103 had requestKind=review-summary and source=review_model
• 87 were hash-object
• 14 were diff
• 104 were aborted or aborted before start
• all 106 reported unsuccessful completion

The repository itself does not appear pathological: it has 20,159 tracked files, 18 visible untracked files, and 29 tracked changes. A normal git status --porcelain completed in about 1.72 seconds, and standard Unity-generated directories are ignored.

This looks like the same process-management/WMI amplification described in the WMI-specific report on this issue, and the current update has not resolved it. The strongest correlation in my Codex logs is the repeated, mostly aborted review-summary Git workload combined with repeated PowerShell Win32_Process enumeration and taskkill /t cleanup.

I have a sanitized evidence summary and can provide a reviewed/redacted copy of the dedicated Git log if that would help. I have not attached the general desktop log because it may contain unrelated task content.

codex-wmi-sanitized-evidence-2026-07-22.txt

I am experiencing the same issue, with severe system instability.

Environment

• Windows 11 Pro x64
• 128 GB RAM
• Codex/ChatGPT desktop app version: 26.715.7063.0
• Git for Windows
• PowerShell
• Large Node.js/Next.js/Vendure project

Symptoms

Simply opening the project and its task in Codex Desktop creates dozens of “Git for Windows” processes, even when I have not requested any Git operation.

During this:

• WMI Provider Host repeatedly uses approximately 20–25% CPU
• computer fans run at full speed
• Codex and other applications become unstable or crash
• many small git.exe processes remain visible in Task Manager
• I have also observed leftover taskkill.exe and conhost.exe processes
• the problem can continue after the visible Git activity should have finished
• restarting Windows temporarily clears the processes, but opening the Codex project triggers them again

This has happened repeatedly for several days.

Isolation already performed

I have tried all of the following:

• completely closed Codex CLI
• closed Docker Desktop
• used only one Codex Desktop task and one agent
• restarted Windows several times
• reset the Codex/ChatGPT desktop app
• removed old temporary worktrees and duplicate project folders
• cleaned generated and disposable project files
• reopened only the canonical project directory
• confirmed that normal Git CLI usage works on this repository

Claude CLI and ordinary Git commands can work with the same project on the same computer without producing this behavior. The repeated process spawning and WMI load appear specifically connected to Codex Desktop’s automatic repository handling.

Reproduction

1. Restart Windows.
2. Open Codex Desktop.
3. Open an existing Git project.
4. Open its task from the sidebar.
5. Watch Task Manager.
6. Many “Git for Windows” processes appear, followed by elevated WMI Provider Host activity and full-speed fans.

No explicit Git action is required.

Requested fixes

Please consider:

• never running git add -A as part of passive project or task opening
• deduplicating and serializing automatic repository checks
• limiting the number of concurrent Git child processes
• cancelling and cleaning up child processes when a task is interrupted or closed
• preventing repeated retries after repository-check failures
• adding a setting to disable automatic Git integration entirely
• exposing diagnostics showing which Codex component launched each Git process

I can provide sanitized screenshots and process details. This is not just normal load from a large repository; it causes sustained WMI activity, system instability, and repeated application crashes on a machine with 128 GB RAM.

I reproduced and traced one concrete unbounded fan-out path in this issue family on Windows, and prepared a tested patch. This targets the per-untracked-file git diff --no-index path; it does not claim to fix the separate git add, taskkill/WMI, retry, or orphan-reaping paths also discussed here.

Reproduction evidence

• Codex Desktop package: OpenAI.Codex_26.721.3996.0
• One affected workspace exposed 33,017 untracked, non-ignored files, mostly generated tmp/ and work/ content.
• During two observed bursts, the Codex/ChatGPT desktop process tree reached a peak of 451 live Git processes across 306 Git roots.
• The local containment log recorded 85 remediation events and 2,250 terminated Codex-owned Git processes across July 24-25.
• After ignoring only the generated directories, the visible untracked set fell from 33,017 to 27. A subsequent 25-second live sample saw no new Git process.

Source-level root cause

On current main at 4c43465133428898aa84f0bfc02c306ed65fb66a, codex-rs/git-utils/src/info.rs::diff_against_sha():

1. runs git ls-files --others --exclude-standard,
2. creates one git diff --no-index future for every returned file, and
3. executes all of them through join_all with no concurrency or file-count bound.

This matches the per-file git diff --no-index command reported above and means a generated/unignored directory can translate directly into thousands of simultaneous Git-for-Windows subprocesses. Repeated gitDiffToRemote requests can multiply the load further because the app-server path currently recomputes the diff.

Proposed partial fix

I prepared a focused branch that:

• preserves parallel diff processing,
• caps concurrent untracked-file diff subprocesses at 8,
• includes at most 32 untracked files per diff request, and
• emits an explicit omitted-files marker when the cap is exceeded.

Patch:

• Draft in fork: https://github.com/rimiehe-svg/codex/pull/1
• Upstream comparison: https://github.com/openai/codex/compare/main...rimiehe-svg:codex:agent/bound-untracked-git-diff-fanout
• Commit: https://github.com/rimiehe-svg/codex/commit/74c724faa72ddfb2cca3765f00f5c2f33eb9e9da

Validation:

• just test -p codex-git-utils — 25/25 passed, including a new 33-file regression test
• just fix -p codex-git-utils
• cargo fmt --all
• git diff --check

The upstream repository currently restricts external PRs to invited contributors, so I could not open a cross-fork PR. Maintainers are welcome to inspect/cherry-pick the commit, or invite an upstream PR if this approach matches the intended fix.