Codex Desktop on Windows eagerly runs review-summary Git snapshots on restored workspaces, causing CPU/IO spikes

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

• #30612
• #30477
• #30345
• #29388

Powered by Codex Action

Additional confirmation from Windows Desktop OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0.

I hit the same review-summary/Git-worker failure mode in a local workspace (D:\codex work) that had become a Git repo with no root .gitignore. The workspace contained large generated/runtime trees such as .mineru-venv/, .codex/vendor/, toolchain/, node_modules/, and installed skill packs.

Observed evidence:

• git status --short --untracked-files=all | Measure-Object reported 108072 untracked paths.
• Codex Desktop logs under %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\07\06 grew to multiple ~5-10 MB files.
• The log tail showed method=review-summary, workerId=git, Git warnings for thousands of paths, then:

error: open(".mineru-venv/bin/python"): Function not implemented
error: unable to index file '.mineru-venv/bin/python'
fatal: adding files failed

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.

Hello, I made a script to just disable this feature until it is fixed. Went from freezlock level of storms to perfect smoothness.

Repo is here, also enables remote control on windows for #28919

https://github.com/zdaar/codex-hacks

<img width="218" height="113" alt="Image" src="https://github.com/user-attachments/assets/1fbd4f3b-bf93-4723-9034-ff13c6b0c0ca" />

The eager review-summary snapshots and git hash-object activity here are especially close to the Changes/Review trigger I reproduced.

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.

Additional controlled reproduction on the current Windows build

I reproduced the same underlying review_model problem on:

• Microsoft Store package: OpenAI.Codex_26.715.10079.0_x64__2p2nqsd0c76g0
• Internal desktop build: 26.715.72359
• Windows NT 10.0.26200.0 x64
• Git for Windows 2.55.0.windows.3
• 32 logical processors

This reproduction extends the original report because the trigger is not limited to application startup, workspace restoration, a repository without HEAD, or tens of thousands of untracked files.

The affected repository had 278 changed paths. Every time I opened or switched to a conversation inside that project, total system CPU reached nearly 100% for approximately 15-30 seconds. No agent task, explicit Git command, or review action was required.

Read-only inspection of the current renderer bundle showed that review-navigation-model-*.js defines both of these automatic live queries:

• review-summary
• branch-diff-stats

An approximately 11-second WPR trace captured 2,422 processes created from the Codex workload, including:

• 452 git hash-object
• 486 git config
• 483 taskkill.exe
• 969 conhost.exe

During the same capture, WPR attributed approximately 32.71% system CPU to WmiPrvSE.exe and 9.68% to the Winmgmt service.

Controlled A/B isolation

I first disabled only the Electron app-state process snapshot path. The CPU spike still reproduced on every project-chat open.

Holding that mitigation constant, I then applied an unsupported in-memory diagnostic bypass that disabled only the renderer's review-summary and branch-diff-stats live queries. The installed MSIX package and app.asar were not modified.

After restarting the app:

• repeated conversation opens in the same repository no longer caused the CPU spike;
• chats, projects, agent Git commands, and normal workspace operations continued to work;
• only automatic full-review file metadata and added/deleted line statistics were unavailable.

A 30-second control capture after disabling the two queries showed:

• ChatGPT.exe: 0.70% average system CPU;
• ChatGPT.exe: 3.63% peak system CPU;
• WmiPrvSE.exe: 0%;
• zero new PowerShell process-snapshot helpers;
• zero matching WMI activity events.

This strongly isolates the immediate trigger to automatic review-summary / branch-diff-stats execution during normal conversation navigation.

The product fix should keep these queries disabled until a review-related surface actually needs them, deduplicate and cancel obsolete calculations, cache results by repository state, and batch per-file Git work instead of spawning separate Git processes.