›_ Codex Issues
Codex Issues / #32113

Windows Desktop scans saved but inactive large Git repositories with ls-files --others, causing high CPU

Open 💬 3 comments Opened Jul 10, 2026 by kyriewxcode
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop on Windows can start an expensive untracked-file scan for a very large, valid Git repository after that repository is saved as a project, even when it is not the active workspace.

The hot process tree is owned by Codex:

ChatGPT.exe
  -> C:\Program Files\Git\cmd\git.exe
     -c core.hooksPath=NUL
     -c core.fsmonitor=
     ls-files --others --exclude-standard -z
  -> C:\Program Files\Git\mingw64\bin\git.exe

The inner git.exe saturates roughly one CPU core for a prolonged period. Removing the repository from Codex's saved projects and terminating only the Codex-owned Git process tree stops the load; no Git/TGitCache processes respawned during the immediate post-removal observation window.

Environment

  • Windows 11
  • Codex Desktop: 26.707.3748.0
  • Git for Windows: 2.47.0.windows.1
  • Repository: large, valid Unreal Engine source tree
  • Approximately 258,000 tracked entries
  • Repository is local, not a broken or empty .git directory
  • TortoiseGit cache was disabled during the reproduction

Real usernames and repository paths are intentionally redacted.

Measurements

A targeted comparison in the affected repository showed:

  • Cached tracked-file listing: approximately 0.2 s
  • git ls-files --others --exclude-standard -z: approximately 14.1 s
  • Only one untracked file was returned in that measurement
  • The most expensive traversal was under large tracked source/plugin/third-party trees

During a later occurrence, the Codex-owned inner Git process had already accumulated about 25 CPU seconds while running the same untracked-file query.

Another direct capture from the same Codex installation included a path-scoped variant against the engine tree:

ChatGPT.exe -> git.exe -> git.exe ls-files ... -- Engine

Reproduction

  1. Start Codex Desktop without the large repository saved/active.
  2. Observe that no persistent git.exe / TGitCache.exe CPU load is present.
  3. Add the large valid repository to Codex's saved projects.
  4. Keep another project active, or switch away from the large repository.
  5. Observe Codex spawning git ls-files --others --exclude-standard -z.
  6. Remove the large repository from saved projects and terminate the currently running Codex-owned Git process tree.
  7. The Git CPU load stops.

In the local state capture, the repository had been added to electron-saved-workspace-roots while another workspace remained in active-workspace-roots. The expensive scan still appeared. This suggests saved/inactive repositories may be eligible for Git discovery or review refresh.

Expected behavior

  • Saved but inactive repositories should not be continuously or eagerly scanned.
  • Untracked-file discovery should be debounced/cached and bounded for very large worktrees.
  • Codex should cancel and reap obsolete Git scans when the project is switched or removed.
  • Ideally expose a per-project option to disable background Git discovery/status polling.

Actual behavior

Saving the large repository is enough to make Codex initiate an expensive untracked-file traversal. On Windows, this produces visible git.exe CPU load and can make the machine sluggish.

Troubleshooting already attempted

The following did not solve the ls-files --others cost and were reverted:

  • core.fsmonitor=true
  • Git untracked cache
  • feature.manyFiles
  • index version 4
  • broad repository exclude experiments

A watchdog that kills Codex-owned Git processes was also rejected as a workaround because Codex retries and its modified/untracked-file UI becomes unreliable.

Related reports

  • #22085
  • #26812
  • #29408
  • #29911 is related to invalid/empty .git directories, but this reproduction uses a valid large repository.
  • #30235 and #30863 appear adjacent, but neither currently addresses Windows saved/inactive repository polling plus the expensive ls-files --others path.

I can provide a short, redacted process trace or run a focused diagnostic build if maintainers need more data.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #30820

Powered by Codex Action

liujianhao1226-beep · 1 month ago

Confirmation: same review-summary → git abort → taskkill storm on Windows Desktop 26.715.7063.0

This matches the chain described in #30820 / #33776 / #32113 / #27570. Local evidence below (no prompt content, no secrets).

Environment

  • OS: Windows 11, PowerShell
  • Codex Desktop package: OpenAI.Codex 26.715.7063.0 (OpenAI.Codex_2p2nqsd0c76g0)
  • Previously also reproduced on 26.715.4045.0; in-app update did not fix
  • Git itself is healthy in the affected repos (git status ~50–65 ms, no merge/rebase/index.lock, fsck --connectivity-only OK)

Symptom

  1. Open Codex Desktop → CPU rises quickly; Task Manager freezes/lags when refreshing process list
  2. Fully quit Desktop (window + tray) → process storm stops immediately
  3. Even when opening a clean worktree via codex://threads/new?path=..., background work still targets a previously saved local project in the sidebar

15s process sample (during active storm, post-update)

PID-diffing style sampler (unique short-lived PIDs over 15s):

| Metric | Value |
| --- | --- |
| Unique taskkill.exe | 262 (~17.5/s) |
| Unique git.exe | 226 (~15.1/s) |
| ChatGPT CPU seconds (15s window) | 5.88 |
| ChatGPT processes | 8 |

Baseline with Desktop fully exited: UniqueTaskkill=0, no ChatGPT/CodexMicroService.

Desktop log signature (exact fields)

Log root:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\

Repeated pattern:

requestKind=review-summary
source=review_model
failureReason=aborted
failureReason=abortedBeforeStart
failureReason=spawnFailed
failureReason=waitFailed
errorMessage="Git snapshot became stale"

Aborted Git subcommands observed:

  • git hash-object
  • git diff --no-index (per untracked file, e.g. scratch/*.py)
  • git diff --cached
  • git status
  • git diff against HEAD for a small set of tracked changes

Trigger cwd in current session (redacted base):

cwd=D:/AI/<local-project-A>

Also previously observed on a second local monorepo under the same parent folder.

Representative command shapes (same as other reports):

git -c core.hooksPath=NUL -c core.fsmonitor= hash-object -- <path>
git ... diff --no-index --raw --numstat -z -- /dev/null scratch/<file>.py
git ... diff --cached <HEAD> --no-renames --name-only -z

Also saw sidebar PR chip work against the same cwd:

requestKind=gh-pr-status
source=sidebar_task_pr_chip
cwd=D:/AI/<local-project-A>

Two-day log aggregation (local)

From recent non-empty Desktop logs:

  • review-summary-related Git complete lines: 4476
  • Early-cancel lines without cwd: 3706 (all failed/aborted)
  • One dirty monorepo cwd: 742 lines (710 failed/aborted)
  • Another dirty project cwd: 28 lines (all failed/aborted)
  • Git snapshot became stale: 55

Important negative findings (not root cause)

  • Not a merge/rebase conflict, index.lock, or corrupt object DB
  • Not continuous on-disk mutation: 10s mtime/size compare of dirty paths showed 0 changing files while snapshot still went stale
  • Not slow Git: git status ~65 ms in the hottest project
  • Defender / WMI / Task Manager behave as amplifiers/victims, not the primary producer (matches #33776 control experiment: kill ChatGPT → storm collapses)
  • Linked clean worktree for another project briefly looked healthy, then logs showed the storm was still scanning <local-project-A> restored from sidebar / local projects — clean worktree alone is not a durable fix

Global state / project registry shape

.codex-global-state.json contained multiple local-projects entries and a selected-project pointing at the dirty project. Desktop restored/scanned that project even when the user deep-linked into a different clean path. This aligns with #32113 (saved/inactive projects still scanned) and #30820 (startup restore → eager review-summary).

Workspace shape that amplifies (not required for the bug, but makes it severe)

Hot project approximately:

  • ~7 tracked modifications/deletions
  • large untracked tree under scratch/ (order of ~90+ files) plus other untracked dirs
  • .gitignore did not cover scratch/diagnostics dumps
  • No nested-repo fanout proven in this capture (unlike #27570), but untracked-per-file hash-object / diff --no-index is enough to feed the cancel/taskkill loop on Windows

A/B already tried (local)

| Attempt | Result |
| --- | --- |
| App update 26.715.4045 → 26.715.7063 | Still reproduces |
| Clean linked worktree deep-link | Current project quiet; other saved project still storms |
| Precise .git/info/exclude | Did not stop loop |
| git add -N intent-to-add | Did not stop; reverted |
| Fully exit Desktop | Storm stops immediately |

Request

Please treat this as another independent Windows confirmation on 26.715.7063.0 of:

  1. Eager/live review-summary / review_model over restored or saved local projects
  2. Per-file untracked Git fanout + abort
  3. taskkill /T /F cleanup feedback loop freezing process enumeration / Task Manager

Happy to validate a patched Desktop build quickly. Can also provide sanitized log excerpts on request.

suiyuebaobao · 1 month ago

The scanning of saved but inactive large repositories with ls-files --others here is the same class of background Git refresh workload I reproduced.

I published a single-file Windows launcher for the original Microsoft Store/MSIX Codex app:

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.