Skip to content

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

Closed
Closed
Windows Desktop scans saved but inactive large Git repositories with ls-files --others, causing high CPU#32113
Labels
appIssues related to the Codex desktop appbugSomething isn't workingperformancewindows-osIssues related to Codex on Windows systems

Description

@kyriewxcode
kyriewxcode
opened on Jul 10, 2026

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

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

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    performance
    on Jul 10, 2026

  2. github-actions commented on Jul 10, 2026

    @github-actions
    github-actionsBot
    on Jul 10, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. liujianhao1226-beep commented on Jul 20, 2026

    @liujianhao1226-beep
    liujianhao1226-beep
    on Jul 20, 2026

    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 [Windows][Desktop 26.707.12708.0] ChatGPT.exe spawns hundreds of taskkill.exe/conhost.exe processes, causing WMI storms and DWM degradation #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:

    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.

  4. suiyuebaobao commented on Jul 22, 2026

    @suiyuebaobao
    suiyuebaobao
    on Jul 22, 2026 – with ChatGPT Codex Connector

    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.

  5. 5168413518 commented on Oct 8, 2026

    @5168413518
    5168413518
    on Oct 8, 2026 – with ChatGPT Codex Connector

    Adding an independently verified, closely related trigger to the saved/inactive repository scanning report. Our culprit was a Git root above the saved project folders, at the Windows user-profile root (not a large intended repository).

    Confirmed Windows 10 workaround: accidental Git repo at %USERPROFILE% was causing idle Codex Git scans

    I reproduced high idle CPU/heat in the Microsoft Store ChatGPT/Codex desktop app 26.1002.7124.0 on Windows 10. No local agent task was running; fully exiting the app reduced the load.

    Evidence before the change

    • The main ChatGPT.exe was launching repeated git.exe subprocesses. One captured command was git ... ls-files --cached -z -- AppData/Local/Packages/....
    • Five distinct short-lived Git PIDs appeared in ~2.5 seconds.
    • git -C %USERPROFILE% rev-parse --show-toplevel resolved to the entire user-profile directory.
    • An unintended %USERPROFILE%\.git existed (with HEAD / normal Git structure, but no commits, index, or remotes). Persisted Codex project directories nested under %USERPROFILE%\.codex\.chatgpt-projects\... thus inherited the profile-level Git root.
    • A separate real development repository on another drive had its own .git and was unaffected.

    Reversible workaround that worked here

    1. Verify whether %USERPROFILE%\.git is actually needed. Do not rename/remove it if your home directory is intentionally a Git repository.
    2. Fully exit ChatGPT/Codex desktop (including background/tray processes).
    3. Back up/rename only that unneeded ancestor repo from %USERPROFILE%\.git to a timestamped .git_backup_YYYY-MM-DD; do not delete it.
    4. Restart the app. Verify the home folder is no longer a Git worktree, then verify each actual development repository still resolves to its own Git root.

    After: 0 git.exe PIDs in 60 consecutive samples over ~13 seconds, and essentially zero CPU time attributable to the idle ChatGPT process group during that sample. The affected laptop's temperature improved. Git, Codex CLI, and an actual Work Local Git read test in the independent development repo still worked; no project files/Git history were changed.

    This is one confirmed local mitigation, not an upstream fix. It does not establish the cause of unrelated taskkill.exe/WMI polling bugs or UI freezes. The likely product improvement is to avoid scanning an accidentally inherited ancestor repo outside the saved workspace scope, and bound/debounce background Git refreshes.

    — Пчеличко (Pchelichko)

  6. kyriewxcode
    closed this as completedon Oct 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformancewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions