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

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.