›_ Codex Issues
Codex Issues / #34473

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

Open 💬 4 comments Opened Jul 21, 2026 by jodagreyhame
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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?

  1. Windows 11, Codex App (MSIX) 26.715.7063.0.
  2. A workspace root containing many git repositories (here: 311).
  3. Ensure at least one .git path that git cannot resolve a root from exists in that tree — in our case an empty .git directory (0 entries).
  4. Launch the Codex App and let it scan.
  5. Watch durationMs in %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:

  1. Backoff + circuit breaker — a failing path must not be retried immediately, and repeated failures should disable scanning for that path.
  2. Cache negative results — an unresolvable path should be remembered, not re-probed 145 times.
  3. Bound concurrency — cap in-flight git.exe processes. Today, failures multiply the process count without limit, which is what converts a slow scan into machine-wide starvation.
  4. Validate before spawning — an empty .git directory 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:

  1. PowerShell/WMI process sampler. electron-sampler shells out to a cold powershell.exe -NoProfile -NonInteractive running both Get-CimInstance Win32_PerfFormattedData_PerfProc_Process and Get-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 the svchost [Winmgmt] figures above. A native API (NtQuerySystemInformation / Toolhelp32) would remove this entirely.
  1. Completed-rollout replay. ~/.codex/sessions here is 9.7 GB across 2,402 files, largest single rollout 913 MB; logs_2.sqlite is 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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33450

Powered by Codex Action

jodagreyhame · 1 month ago

<html>
<body>
<!--StartFragment--><p data-line="7" class="code-line" dir="auto" style="margin-top: 0px; margin-bottom: 16px; color: rgb(187, 190, 191); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe WPC&quot;, &quot;Segoe UI&quot;, system-ui, Ubuntu, &quot;Droid Sans&quot;, sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><strong>Correction and follow-up to my own report above.</strong></p><p data-line="9" class="code-line" dir="auto" style="margin-top: 0px; margin-bottom: 16px; color: rgb(187, 190, 191); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe WPC&quot;, &quot;Segoe UI&quot;, system-ui, Ubuntu, &quot;Droid Sans&quot;, sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">The original text says removing the empty<span> </span><code style="font-family: Consolas, &quot;Courier New&quot;, monospace; color: rgb(140, 140, 140); background-color: rgb(38, 38, 38); padding: 1px 3px; border-radius: 4px; font-size: 1em; line-height: 1.357em;">.git</code><span> </span>directory<span> </span><em>"eliminated the behaviour entirely."</em><span> </span><strong>That was overstated.</strong><span> </span>Longer observation shows the fix was real but only partial.</p><h3 data-line="13" class="code-line" dir="auto" id="what-still-holds" style="margin-top: 24px; font-weight: 600; margin-bottom: 16px; line-height: 1.25; font-size: 1.25em; color: rgb(187, 190, 191); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe WPC&quot;, &quot;Segoe UI&quot;, system-ui, Ubuntu, &quot;Droid Sans&quot;, sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">What still holds</h3><p data-line="15" class="code-line" dir="auto" style="margin-top: 0px; margin-bottom: 16px; color: rgb(187, 190, 191); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe WPC&quot;, &quot;Segoe UI&quot;, system-ui, Ubuntu, &quot;Droid Sans&quot;, sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">The git-root retry loop<span> </span><strong>is</strong><span> </span>driven by an unresolvable<span> </span><code style="font-family: Consolas, &quot;Courier New&quot;, monospace; color: rgb(140, 140, 140); background-color: rgb(38, 38, 38); padding: 1px 3px; border-radius: 4px; font-size: 1em; line-height: 1.357em;">.git</code><span> </span>path, and removing it did eliminate<span> </span><em>that</em><span> </span>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.</p><h3 data-line="20" class="code-line" dir="auto" id="what-does-not-hold" style="margin-top: 24px; font-weight: 600; margin-bottom: 16px; line-height: 1.25; font-size: 1.25em; color: rgb(187, 190, 191); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe WPC&quot;, &quot;Segoe UI&quot;, system-ui, Ubuntu, &quot;Droid Sans&quot;, sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">What does not hold</h3><p data-line="22" class="code-line" dir="auto" style="margin-top: 0px; margin-bottom: 16px; color: rgb(187, 190, 191); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe WPC&quot;, &quot;Segoe UI&quot;, system-ui, Ubuntu, &quot;Droid Sans&quot;, sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><strong>The machine was still driven to 100% CPU twice more, and once more had to be forcibly powered off.</strong></p><p data-line="24" class="code-line" dir="auto" style="margin-top: 0px; margin-bottom: 16px; color: rgb(187, 190, 191); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe WPC&quot;, &quot;Segoe UI&quot;, system-ui, Ubuntu, &quot;Droid Sans&quot;, sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">A monitor sampling<span> </span><code style="font-family: Consolas, &quot;Courier New&quot;, monospace; color: rgb(140, 140, 140); background-color: rgb(38, 38, 38); padding: 1px 3px; border-radius: 4px; font-size: 1em; line-height: 1.357em;">git.exe</code><span> </span>count and total CPU every ~10 s recorded this after the fix:</p><pre style="margin-top: 0px; background-color: rgb(36, 37, 38); border-color: rgb(42, 43, 44); border-style: solid; border-width: 1px; border-image: none 100% / 1 / 0 stretch; padding: 16px; border-radius: 3px; overflow: auto; white-space: pre-wrap; color: rgb(187, 190, 191); font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><code data-line="26" class="code-line" dir="auto" style="font-family: Consolas, &quot;Courier New&quot;, monospace; color: rgb(187, 190, 191); background: none; padding: 0px; border-radius: 4px; font-size: 1em; line-height: 1.357em; display: inline-block; tab-size: 4;">15:28:41 BAD START stuck_git=4 cpu=25% ← brief git pile-up
15:29:16 RECOVERED after 34s stuck_git=0 ← self-cleared, did NOT run away
...
15:38:59 BAD START stuck_git=0 cpu=100% ← saturated with NO git loop at all
15:39:27 sustained 27s cpu=100% stuck_git=0
</code></pre><p data-line="34" class="code-line" dir="auto" style="margin-top: 0px; margin-bottom: 16px; color: rgb(187, 190, 191); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe WPC&quot;, &quot;Segoe UI&quot;, system-ui, Ubuntu, &quot;Droid Sans&quot;, sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">That second event is the important one:<span> </span><strong>total CPU pinned at 100% with<span> </span><code style="font-family: Consolas, &quot;Courier New&quot;, monospace; color: rgb(140, 140, 140); background-color: rgb(38, 38, 38); padding: 1px 3px; border-radius: 4px; font-size: 1em; line-height: 1.357em;">stuck_git=0</code></strong><span> </span>— no git activity whatsoever.</p><p data-line="37" class="code-line" dir="auto" style="margin-top: 0px; margin-bottom: 16px; color: rgb(187, 190, 191); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe WPC&quot;, &quot;Segoe UI&quot;, system-ui, Ubuntu, &quot;Droid Sans&quot;, sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">A later incident the same day ended in another forced power-off. Per-process attribution from Windows SRUM for that window:</p>
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.exe

<p data-line="47" class="code-line" dir="auto" style="margin-top: 0px; margin-bottom: 16px; color: rgb(187, 190, 191); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe WPC&quot;, &quot;Segoe UI&quot;, system-ui, Ubuntu, &quot;Droid Sans&quot;, sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Worst single sample in that window:<span> </span><code style="font-family: Consolas, &quot;Courier New&quot;, monospace; color: rgb(140, 140, 140); background-color: rgb(38, 38, 38); padding: 1px 3px; border-radius: 4px; font-size: 1em; line-height: 1.357em;">svchost[Winmgmt]</code><span> </span>at<span> </span><strong>76,846,768</strong>, about 9× the next process. This matches the first incident in the original report almost exactly (<strong>247,725,988</strong><span> </span>there), and in both cases Codex Desktop was running.</p><h3 data-line="51" class="code-line" dir="auto" id="what-that-means" style="margin-top: 24px; font-weight: 600; margin-bottom: 16px; line-height: 1.25; font-size: 1.25em; color: rgb(187, 190, 191); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe WPC&quot;, &quot;Segoe UI&quot;, system-ui, Ubuntu, &quot;Droid Sans&quot;, sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">What that means</h3><p data-line="53" class="code-line" dir="auto" style="margin-top: 0px; margin-bottom: 16px; color: rgb(187, 190, 191); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe WPC&quot;, &quot;Segoe UI&quot;, system-ui, Ubuntu, &quot;Droid Sans&quot;, sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">There are (at least)<span> </span><strong>two independent CPU mechanisms</strong><span> </span>in this app on Windows, and they must be fixed separately:</p><ol data-line="56" class="code-line" dir="auto" style="margin-top: 0px; margin-bottom: 0.7em; color: rgb(187, 190, 191); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe WPC&quot;, &quot;Segoe UI&quot;, system-ui, Ubuntu, &quot;Droid Sans&quot;, sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><li data-line="56" class="code-line" dir="auto"><p data-line="56" class="code-line" dir="auto" style="margin-top: 0px; margin-bottom: 0.7em;"><strong>The unbounded git-root retry loop</strong><span> </span>— this report. Triggered by an unresolvable<span> </span><code style="font-family: Consolas, &quot;Courier New&quot;, monospace; color: rgb(140, 140, 140); background-color: rgb(38, 38, 38); padding: 1px 3px; border-radius: 4px; font-size: 1em; line-height: 1.357em;">.git</code>; removing the trigger stops it.<span> </span><strong>But removing individual triggers is not a fix</strong><span> </span>— 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.</p></li><li data-line="61" class="code-line" dir="auto"><p data-line="61" class="code-line" dir="auto" style="margin-top: 0px; margin-bottom: 0.7em;"><strong>The<span> </span><code style="font-family: Consolas, &quot;Courier New&quot;, monospace; color: rgb(140, 140, 140); background-color: rgb(38, 38, 38); padding: 1px 3px; border-radius: 4px; font-size: 1em; line-height: 1.357em;">electron-sampler</code><span> </span>PowerShell/WMI storm</strong><span> </span>— tracked in<span> </span><strong>#29499</strong>, filed from this same OS build (26200).<span> </span><strong>This one is sufficient on its own to saturate the machine</strong>, as the<span> </span><code style="font-family: Consolas, &quot;Courier New&quot;, monospace; color: rgb(140, 140, 140); background-color: rgb(38, 38, 38); padding: 1px 3px; border-radius: 4px; font-size: 1em; line-height: 1.357em;">stuck_git=0 / cpu=100%</code><span> </span>sample above demonstrates. It displaces its cost into<span> </span><code style="font-family: Consolas, &quot;Courier New&quot;, monospace; color: rgb(140, 140, 140); background-color: rgb(38, 38, 38); padding: 1px 3px; border-radius: 4px; font-size: 1em; line-height: 1.357em;">svchost[Winmgmt]</code>, so it is invisible if you only look at Codex's own process CPU.</p></li></ol><p data-line="66" class="code-line" dir="auto" style="margin-top: 0px; margin-bottom: 16px; color: rgb(187, 190, 191); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe WPC&quot;, &quot;Segoe UI&quot;, system-ui, Ubuntu, &quot;Droid Sans&quot;, sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">I've added the SRUM data to #29499 separately.</p><h3 data-line="68" class="code-line" dir="auto" id="net" style="margin-top: 24px; font-weight: 600; margin-bottom: 16px; line-height: 1.25; font-size: 1.25em; color: rgb(187, 190, 191); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe WPC&quot;, &quot;Segoe UI&quot;, system-ui, Ubuntu, &quot;Droid Sans&quot;, sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><!--EndFragment-->
</body>
</html>

suiyuebaobao · 1 month ago

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 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.

butlerwill1 · 15 days ago

Independent corroborating reproduction on a newer Windows Codex App build, with a different apparent trigger.

Environment

  • Windows 11 x64, build 26200
  • Codex App MSIX: 26.803.10989.0
  • Git for Windows: 2.55.0.windows.3
  • Workspace was one valid Git repository (not a broad multi-repository root); ordinary git status was measured at about 60 ms beforehand.

Observed trigger / reproduction

  1. Started an independent PowerShell monitor sampling Windows commit, git.exe count, and process handles every 2 seconds.
  2. Connected to the Windows host through Codex Remote in the ChatGPT mobile app and opened the existing task.
  3. Soon afterwards, without deliberately opening the Review/Changes view, the Windows host entered an unbounded git.exe storm.

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

  • Baseline: committed memory ~34–35%, 0 git.exe.
  • Within roughly 2 minutes: 1,244 simultaneous git.exe processes visible in the monitor; committed memory rose to 66.67%.
  • At protective intervention: 1,481 simultaneous git.exe processes; the Codex process had ~124,872 handles.
  • A 70% commit warning then fired. We terminated Codex and all git.exe processes before the host froze.
  • Recovery was immediate: git.exe count 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 .git path is not known to be present here. The workspace is a normal repository, and a direct git status --porcelain=v1 --untracked-files=no completed 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.