Repository navigation
Codex App (Windows): an unresolvable git root causes an unbounded, no-backoff retry loop that saturates the entire machine — 142/168 git calls hit the 60s timeout #34473
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.715.52143
What subscription do you have?
Pro
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Codex App's git-root resolution retries without any backoff, circuit breaker, or negative-result cache. When a single path cannot be resolved, the retries compound until the entire machine is CPU-starved. This is not a slow-scan complaint — the machine became unusable and had to be force-powered-off.
The amplification, from the app's own logs. Codex launched at 13:18:28. Sixteen seconds later its git worker began degrading. Raw durationMs values, 13:18:44 → 13:19:36:
5,506 → 6,762 → 22,184 → 21,621 → 24,783 → 27,145 → 42,964 → 33,029 → 49,691 ms
→ then pinned at the 60,000 ms timeout ceiling, permanently
For reference, git config --get remote.origin.url completes in 10–40 ms on this hardware.
Aggregate over the session:
| Metric | Value |
|---|---|
| git commands issued | 168 |
| git commands that timed out | 142 (85%) |
| Median duration of timed-out calls | 60,007 ms |
| Duration of the loop | 54 minutes |
worker_rpc_response_error "Failed to resolve git root" |
160 |
…explicitly git process timed out after 60000ms |
145 |
| Repositories successfully scanned | 15 of 311 |
The loop:
renderer → worker: resolve git root
worker → spawn git.exe
git.exe → hangs, 60 s timeout
worker → worker_rpc_response_error "Failed to resolve git root: git process timed out after 60000ms"
renderer → RETRY IMMEDIATELY ← no backoff, no circuit breaker, no failure cache
Each retry adds another 60-second git.exe to an already-starved machine, which makes the next git call slower still. This is positive feedback, not a plateau — it never self-limits.
Impact. This is a 16-core / 32-thread / 96 GB workstation. It was fully saturated by the app's git scanner. The desktop became unresponsive and required a forced power-off after 54 minutes. It has happened 3 times in 48 hours; on one occasion taskkill.exe itself crashed (0xc0000005) while attempting to terminate the app.
Measured CPU attribution (Windows SRUM, powercfg /srumutil). CPU energy attributed to the WMI service (svchost.exe [netsvcs] [Winmgmt]), local time:
| Local time | CPU energy | App state |
|---|---|---|
| 12:38 | 1,213,854 | not running |
| 13:39 | 91,303,917 | Codex launched — 75× jump |
| 14:08 | 74,046,292 | running |
| 14:15+ | 7,000 – 44,000 | not running — ~1000× collapse |
Total for the incident hour: 247,725,988 — the largest single CPU consumer on the machine, exceeding antivirus, shell, editor and a running backup combined. The post-restart period is a clean control.
What steps can reproduce the bug?
- Windows 11, Codex App (MSIX)
26.715.7063.0. - A workspace root containing many git repositories (here: 311).
- Ensure at least one
.gitpath that git cannot resolve a root from exists in that tree — in our case an empty.gitdirectory (0 entries). - Launch the Codex App and let it scan.
- Watch
durationMsin%LOCALAPPDATA%\Packages\OpenAI.Codex_<pkg>\LocalCache\Local\Codex\Logs\<yyyy>\<mm>\<dd>\.
Git durations climb from ~5 s to the 60 s ceiling within about a minute and stay there. The app keeps retrying for as long as it is left running.
Trigger confirmed by controlled test. The unresolvable .git directory was deleted and the app relaunched with no other change — no app update, no antivirus exclusions, session data untouched. A monitor sampled git.exe count and total CPU every ~10 s:
| Before | After (unresolvable .git removed) |
|
|---|---|---|
| ~16 s after launch | durations already ramping (5,506 ms) | no git activity |
| ~52 s after launch | pinned at the 60,000 ms ceiling | 0 git.exe processes |
| Steady state | machine saturated, UI unresponsive | CPU 3–8%, idle |
Long-lived git.exe (>15 s) |
dozens accumulating | 0 |
| Outcome | forced power-off after 54 min | normal operation |
15:10:03 Codex DETECTED: pid=9676 ChatGPT.exe
15:10:04 ok stuck_git=0 cpu=13% codexProcs=6 <- launch
15:10:16 ok stuck_git=0 cpu=50% codexProcs=10 <- normal Electron start-up burst
15:10:27 ok stuck_git=0 cpu=8% codexProcs=10
15:11:57 ok stuck_git=0 cpu=6% codexProcs=10
Removing one empty directory, changing nothing else, eliminated the behaviour entirely.
(Caveat, stated plainly: this is a negative result over a single clean session. It shows the unresolvable path is sufficient to trigger the loop; it does not prove it is the only possible trigger — which is exactly why the retry behaviour needs bounding regardless of how the path arises.)
What is the expected behavior?
The scanner should fail fast and stay failed for a path it cannot resolve:
- Backoff + circuit breaker — a failing path must not be retried immediately, and repeated failures should disable scanning for that path.
- Cache negative results — an unresolvable path should be remembered, not re-probed 145 times.
- Bound concurrency — cap in-flight
git.exeprocesses. Today, failures multiply the process count without limit, which is what converts a slow scan into machine-wide starvation. - Validate before spawning — an empty
.gitdirectory is detectable with a directory read; it does not require spawning git and waiting 60 seconds.
Under no circumstances should a workspace-scanning feature be able to render the host unusable.
Additional information
Two further Codex mechanisms were running concurrently and compounded the load. Neither reproduced the saturation on its own once the git loop stopped, but both add constant overhead:
-
PowerShell/WMI process sampler.
electron-samplershells out to a coldpowershell.exe -NoProfile -NonInteractiverunning bothGet-CimInstance Win32_PerfFormattedData_PerfProc_ProcessandGet-CimInstance Win32_Process, with a PID filter enumerating 118 tracked children. These are the two most expensive process-enumeration calls on Windows (~1–2 CPU-seconds per invocation, fresh .NET start plus WMI provider work). Only failures are logged, and one 122-minute session logged 1,680 failed invocations (7–11/min sustained). This is what drives thesvchost [Winmgmt]figures above. A native API (NtQuerySystemInformation/ Toolhelp32) would remove this entirely. -
Completed-rollout replay.
~/.codex/sessionshere is 9.7 GB across 2,402 files, largest single rollout 913 MB;logs_2.sqliteis 2,147 MB with a live WAL. Every telemetry write is random I/O into a 2 GB SQLite database on the system drive.
Onset correlates with an app update. The 60-second git-timeout signature appears in exactly 3 of ~30 sessions, all within 48 hours, and in none of the ~25 sessions before that. The MSIX package updated on 2026-07-19; the signature begins the following day.
| Session | git timeouts | Outcome |
|---|---|---|
| Day 1, 09:59 → 13:58 | 61 | WER MoAppHang — "Codex is not responding" |
| Day 1, 23:46 → 23:50 | 16 | taskkill.exe crashed (0xc0000005); machine hard-reset |
| Day 2, 13:18 → 14:13 | 142 | Machine forcibly powered off |
Explicitly ruled out as causes of the saturation, with evidence: Windows Update (no update activity in the window); pending disk check (the "hybrid shutdown overridden" event fired 4 ms after the shutdown request and also fires on ordinary shutdowns — a stale flag); disk failure (chkdsk /scan clean, 0 KB in bad sectors, 0 uncorrected read/write errors, 0 wear); hardware/thermal (no WHEA events); memory exhaustion (no Event 2004; 96 GB installed); and one unrelated third-party application that was independently diagnosed and fixed earlier the same day — SRUM confirms it was idle at ~0.2 cores throughout this incident.
Possibly related existing issues: #29911 (empty .git directories being created and rescanned — the source of the unresolvable path in our case), #29499 (WMI/PowerShell sampler; filed from OS build 26200, identical to this machine), #33786 (completed-thread rollout replay; same 26.715 build family), #30527 (antivirus exclusions shift rather than remove the cost).
This report is filed separately from those because the failure documented here is not "a directory gets rescanned" but unbounded retry amplification that terminates in whole-machine starvation and a forced power-off — and because the trigger→fix relationship is confirmed by controlled measurement.
Redaction note: Windows username, hostname, internal project names and session GUIDs have been removed from all excerpts above.
Activity
github-actions commentedon Jul 21, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
jodagreyhame commentedon Jul 21, 2026
Correction and follow-up to my own report above.
The original text says removing the empty
.gitdirectory "eliminated the behaviour entirely." That was overstated. Longer observation shows the fix was real but only partial.What still holds
The git-root retry loop is driven by an unresolvable
.gitpath, and removing it did eliminate that loop. In ~30 minutes of monitoring afterwards there was no recurrence of the runaway: git durations stayed normal instead of ramping to the 60,000 ms ceiling, and there was no 54-minute saturation. The trigger→loop relationship in the original report stands.What does not hold
The machine was still driven to 100% CPU twice more, and once more had to be forcibly powered off.
A monitor sampling
git.execount and total CPU every ~10 s recorded this after the fix:That second event is the important one: total CPU pinned at 100% with
stuck_git=0— no git activity whatsoever.A later incident the same day ended in another forced power-off. Per-process attribution from Windows SRUM for that window:
CPU energy | Process -- | -- 230,184,384 | svchost.exe [netsvcs] [Winmgmt] (the WMI service) 26,021,575 | OpenAI.Codex_26.715.7063.0 23,534,183 | Defender 17,888,118 | taskkill.exeWorst single sample in that window:
svchost[Winmgmt]at 76,846,768, about 9× the next process. This matches the first incident in the original report almost exactly (247,725,988 there), and in both cases Codex Desktop was running.What that means
There are (at least) two independent CPU mechanisms in this app on Windows, and they must be fixed separately:
The unbounded git-root retry loop — this report. Triggered by an unresolvable
.git; removing the trigger stops it. But removing individual triggers is not a fix — the app appears to create these directories itself, and any other unresolvable path would do the same. The retry still needs backoff, a circuit breaker, negative-result caching, and bounded concurrency.The
electron-samplerPowerShell/WMI storm — tracked in Codex triggers high CPU usage in WMI Provider Host on Windows after startup #29499, filed from this same OS build (26200). This one is sufficient on its own to saturate the machine, as thestuck_git=0 / cpu=100%sample above demonstrates. It displaces its cost intosvchost[Winmgmt], so it is invisible if you only look at Codex's own process CPU.I've added the SRUM data to #29499 separately.
suiyuebaobao commentedon Jul 22, 2026
The unresolvable Git root and no-backoff retry loop here are exactly the kind of Git-backed desktop workload that this workaround intentionally blocks.
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 newgit.exeand 137 newtaskkill.exeprocesses 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.
butlerwill1 commentedon Aug 12, 2026
Independent corroborating reproduction on a newer Windows Codex App build, with a different apparent trigger.
Environment
26.803.10989.02.55.0.windows.3git statuswas measured at about 60 ms beforehand.Observed trigger / reproduction
git.execount, and process handles every 2 seconds.git.exestorm.I cannot prove that Mobile Remote alone is the initiating event, but the onset was immediately after that connection and the process/memory behaviour was unambiguous.
Measured result
git.exe.git.exeprocesses visible in the monitor; committed memory rose to 66.67%.git.exeprocesses; the Codex process had ~124,872 handles.git.exeprocesses before the host froze.git.execount returned to 0, committed memory fell to ~38.5%, and Codex handle count fell to ~506 after restart.This was not a historical sample-count artefact: the monitor queried live processes and the 1,481 PIDs were simultaneously present. Each process was small, but the unbounded count rapidly consumed system commit/handles and was headed toward the earlier whole-machine freeze pattern.
Why this may extend #34473
The existing report's malformed/unresolvable
.gitpath is not known to be present here. The workspace is a normal repository, and a directgit status --porcelain=v1 --untracked-files=nocompleted in ~57 ms before the experiment. This looks like another desktop review/workspace-refresh path that can bypass the same essential protections: no bounded concurrency, no effective coalescing, and no circuit breaker.I can provide redacted monitor CSV/event excerpts and app-log excerpts if maintainers want them.
domainersuite commentedon Sep 28, 2026
I am seeing a related Codex Desktop Windows failure with repeated visible terminal windows, each reporting a launch error for an internal Git metadata probe. Two examples captured from the windows:
The active Codex workspace root is
%USERPROFILE%\code. That directory contains an empty.gitdirectory (zero entries, noHEAD). The actual project repository one level below has a valid.git/HEAD, and Git for Windows exists atC:\Program Files\Git\cmd\git.exe. The windows continued after agent commands and subagents stopped, so these specific probes were not commands issued by the agent. Codex's local log identifies the desktop client as26.924.22138.I have not measured Git timeouts or CPU saturation in this case, so I cannot claim the full failure mode in the original report. The empty parent Git marker and repeated internal Git probes make it look related. Please make repository discovery fail fast and avoid opening visible windows for background Git checks. A bounded retry and negative cache for an invalid Git root would help.