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

Summary

Codex Desktop on Windows can trigger severe CPU/IO/memory spikes immediately after launch because the desktop UI restores the last active workspace and eagerly runs review_model / review-summary Git snapshot work against it.

This is not observed with Codex CLI in the same environment. The CLI does not mount the Desktop sidebar/review metadata query stack, while the Desktop app does.

Related but not identical to:

Codex Desktop on Windows exits after background git add -A runs against home directory #27120 (git add -A against the home directory)
Codex Desktop review-summary spawns thousands of git hash-object processes when nested repositories are present #27570 (review-summary / hash-object storms)
Windows desktop app triggers multiple git.exe add -A processes when opening a project/chat, causing severe CPU and disk usage #20933 (Windows desktop spawning many Git processes)

The issue here is the startup/restore trigger chain: restored workspace -> review metadata query -> Git snapshot over thousands of untracked files -> repeated refresh/retry.

Environment

OS: Windows
Codex Desktop package: OpenAI.Codex_26.623.11225.0_x64__2p2nqsd0c76g0
Desktop app path: C:\Program Files\WindowsApps\OpenAI.Codex_26.623.11225.0_x64__2p2nqsd0c76g0\app\Codex.exe
Bundled app-server / CLI reported version: 0.142.5
Launch AppID: OpenAI.Codex_2p2nqsd0c76g0!App
Workspace involved: a large local workspace under D:\Users\<user>\Documents\Playground
Workspace state: Git repo with no valid HEAD / no initial commit, no useful ignore boundary, tens of thousands of files, many untracked files

Observed behavior

Opening Codex Desktop causes the machine to become extremely sluggish. Process monitoring and Desktop logs show Desktop Codex.exe launching Git commands repeatedly.

The important part is that these are not normal git status calls. They are review snapshot commands from Desktop's review metadata path:

source=review_model
requestKind=review-summary
cwd=D:/Users/<user>/Documents/Playground

Examples from Desktop logs:

warning [git] git.command.complete ...
command="git -c core.hooksPath=NUL -c core.fsmonitor= hash-object --no-filters -- <thousands of paths>"
argsCount=5802
cwd=D:/Users/<user>/Documents/Playground
requestKind=review-summary
source=review_model
subcommand=hash-object

warning [git] git.command.complete ...
command="git -c core.hooksPath=NUL -c core.fsmonitor= add -- <thousands of paths>"
argsCount=1026
cwd=D:/Users/<user>/Documents/Playground
requestKind=review-summary
source=review_model
subcommand=add

There was also a failed write-tree from the same path:

warning [git] git.command.complete ...
command="git -c core.hooksPath=NUL -c core.fsmonitor= write-tree"
cwd=D:/Users/<user>/Documents/Playground
requestKind=review-summary
source=review_model
exitCode=1073807364
subcommand=write-tree

A local aggregation of the Desktop log files showed:

total git.command.complete rows: 201
source=review_model: 190
requestKind=review-summary: 185
cwd=D:/Users/<user>/Documents/Playground: 194

The high-cost commands repeat roughly every 15-20 seconds in the captured logs, with hash-object followed by add --.

Startup / restore trigger chain observed

The global state file contains restored workspace state similar to:

electron-saved-workspace-roots:
  - D:\Users\<user>\Practice-Project\202606\Valvekr
  - D:\Users\<user>\Documents\Playground

active-workspace-roots:
  - D:\Users\<user>\Documents\Playground

project-order:
  - D:\Users\<user>\Practice-Project\202606\Valvekr
  - D:\Users\<user>\Documents\Playground

The desktop package's app.asar also shows the path that matches the logs:

webview/assets/review-navigation-model-*.js defines a review-summary query with operationSource / source review_model.
That query uses includeUntrackedFiles=true, staleTime=FIVE_SECONDS, refetchOnWindowFocus=true, and background/error refetch behavior.
.vite/build/worker.js handles case "review-summary" by calling gitManager.getWorktreeRepository(...) and then a review summary implementation that builds temporary worktree/index snapshots.
The worker implementation calls Git operations such as hash-object --no-filters, add, write-tree, and diff --find-renames --numstat/name-status/raw.

In simplified form:

Codex Desktop launch
  -> Electron app-server starts
  -> renderer loads thread/list + workspace/sidebar state
  -> active workspace is restored from global state
  -> review-navigation-model mounts review metadata queries
  -> review_model sends review-summary to Git worker
  -> worker snapshots untracked-aware worktree state
  -> Git scans thousands of untracked files repeatedly
  -> Windows CPU/IO/memory spike

Why this is severe on Windows

This pattern is especially expensive on Windows because Git is being asked to read/hash/add thousands of small files from a large dirty workspace. NTFS small-file IO plus Windows Defender or other real-time scanning can amplify the cost. When the workspace has no valid HEAD/no initial commit and lots of untracked files, review-summary can remain error/stale and be repeatedly refreshed.

This makes Desktop launch feel catastrophic even though Codex CLI works normally on the same machine.

Expected behavior

Codex Desktop should not eagerly run heavyweight review-summary Git snapshot work on restored startup workspaces, especially not with untracked files included by default.

At minimum, Desktop should have guardrails such as:

Do not run review_model / review-summary in the background until the user actually opens a review-related surface.
Do not include untracked files by default for startup/sidebar metadata.
Detect large/no-HEAD/initial repositories and downgrade to cheap metadata only.
Add an untracked file count / path count / elapsed-time limit before running hash-object, add, write-tree, or full diff snapshot work.
Add exponential backoff when review-summary fails, instead of quick stale/error refetch loops.
Surface a warning instead of silently exhausting CPU/IO.

Reproduction shape

On Windows, have a large workspace with many untracked files and no valid HEAD / no initial commit.
Let Codex Desktop remember it as an active workspace in .codex-global-state.json.
Launch Codex Desktop.
Observe Desktop logs under:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\<date>

Search for:

source=review_model
requestKind=review-summary
hash-object --no-filters
write-tree
cwd=<restored workspace>

Workaround notes

Making the affected workspace a clean, committed, tightly ignored Git repo may reduce the impact. However, this is only a workaround. Desktop should not make startup responsiveness depend on every restored workspace being a clean small Git repo.

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

Severe: Codex Desktop can hammer disks in game/media/ML repos with many binary assets, risking SSD wear #30612
Uningnored large data cause massive CPU bound by the worker that are created by Codex for git add and diffs #30477
Windows Desktop background Git probes can create CPU/I/O storms via conhost and AV scanning #30345
Codex turn-diff checkpoint blobs silently consume 100+ GB disk space #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

Open Codex Desktop → CPU rises quickly; Task Manager freezes/lags when refreshing process list
Fully quit Desktop (window + tray) → process storm stops immediately
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:

~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 Codex Desktop review-summary spawns thousands of git hash-object processes when nested repositories are present #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:

Eager/live review-summary / review_model over restored or saved local projects
Per-file untracked Git fanout + abort
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

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.

Related macOS evidence for the cost of background Git metadata, plus a narrow local workaround. I have not reproduced the Windows startup trigger or traced the owning desktop request.

Environment: desktop 26.928.40906 (build 12694), bundled CLI 0.159.2, macOS 26.6.2 arm64, Git 2.54.0 (Apple Git-157), 48 GiB RAM.

Two git diff processes were direct children of the desktop app. One ran in a valid-HEAD research checkout with these flags:

--no-ext-diff --no-textconv --color=never --find-renames --raw --no-abbrev --numstat -z

That process sampled at 91.2% CPU / 49 seconds elapsed / 4,966.33 MiB RSS, but its saved macOS process footprint was only 268.69 MiB. A later Git child sampled at 84.6% CPU / 25 seconds elapsed / 4,290.50 MiB RSS; its cwd was not captured. These observations do not establish a multi-GiB private heap leak or the exact review query responsible.

The first checkout had 9,739 index entries representing 17,785,568,809 bytes of blobs, counting duplicate references, and 9,084 tracked paths absent from the working tree. Its largest CSV blobs were about 97 MiB. Inspection of the installed worker shows review metadata requesting rename detection plus numstat; one path-selection helper falls back to an unscoped diff above 512 paths. A 32 MiB stdout limit does not bound input processing cost. My sampled log failures came from turn_diff_analytics, so I am not treating them as proof of review-summary attribution.

I applied repository-local .git/info/attributes entries with -diff for 495 generated benchmark CSVs whose indexed blobs were >= 8 MiB. On one actual 102,055,983-byte deleted blob, the same raw/numstat command changed from a textual deletion count to - - binary counts. All 495 attributes were verified; source-code diff attributes, HEAD, the index hash and the tracked-change snapshot were unchanged. This follows Git's documented binary diff attribute. The tradeoff is losing textual diffs and line counts for those exact CSVs; removing the local entries restores them. I did not replay the full 16.56 GiB diff or measure whole-app memory savings.

For a product regression, include a valid-HEAD checkout with >512 changed tracked paths and large deleted text blobs. Capture the caller/request ID and enforce input/path/time budgets before eager line counts or rename analysis; make expensive stats demand-driven. An output cap alone misses this workload.

Navigation Menu

Repository navigation

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

Summary

Environment

Observed behavior

Startup / restore trigger chain observed

Why this is severe on Windows

Expected behavior

Reproduction shape

Workaround notes

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

Environment

Symptom

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

Desktop log signature (exact fields)

Two-day log aggregation (local)

Important negative findings (not root cause)

Global state / project registry shape

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

A/B already tried (local)

Request

Additional controlled reproduction on the current Windows build

Controlled A/B isolation

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Observed behavior

Startup / restore trigger chain observed

Why this is severe on Windows

Expected behavior

Reproduction shape

Workaround notes

Activity

github-actions commented on Jul 1, 2026

66666-design commented on Jul 8, 2026

liujianhao1226-beep commented on Jul 20, 2026

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

Environment

Symptom

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

Desktop log signature (exact fields)

Two-day log aggregation (local)

Important negative findings (not root cause)

Global state / project registry shape

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

A/B already tried (local)

Request

zdaar commented on Jul 20, 2026

suiyuebaobao commented on Jul 22, 2026

Sing303 commented on Jul 22, 2026

Additional controlled reproduction on the current Windows build

Controlled A/B isolation

sharifhsn commented on Oct 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions