[Windows 11][26.707 confirmed; 26.727 follow-up] Codex-associated Git churn observed with 9.63 GB Page Table and 95.9% commit

Summary

Codex Desktop on Windows intermittently enters short-lived periods of high process-creation churn. A trace can remain quiet for tens of seconds and then show many git.exe and conhost.exe starts. On 26.707.9981.0, some Git processes were direct children of ChatGPT.exe; this establishes Desktop-host ancestry, but does not by itself distinguish background integration work from a prompt-triggered tool path.

During the same long-running incident, Windows system commit reached 95.9%, available physical memory fell to 1.19 GB, and Microsoft Sysinternals RAMMap reported approximately 9.63 GB under Page Table. The machine became effectively unusable under memory pressure and paging and required a reboot. These observations occurred together, but the available data do not prove that Git/process churn caused all page-table or commit accumulation.

A clean reboot returned memory and kernel-pool measurements to a normal baseline, while Git process creation later reproduced. This shows that reboot cleared the accumulated pressure but did not remove the observed process-creation behavior; it does not identify the exact retained Windows resource or prove that every component of the memory incident had one cause.

Environment

• Codex App: 26.707.9981.0 during the confirmed direct-ancestry incident; follow-up tested on 26.727.6591.0
• OS: Windows 11 Home, 10.0.26100 x64
• Physical RAM: 31.8 GB
• Git for Windows: 2.45.1.windows.1
• RAMMap: Microsoft Sysinternals RAMMap v1.63
• Current selected workspace: local non-Git directory

Local usernames, machine name, workspace paths, repository names, conversation content, and account details are intentionally excluded.

Scope and attribution caveat

• A ChatGPT.exe parent proves that the Desktop host launched the process; it does not by itself identify the internal request kind.
• At least one early short trace may have overlapped another active Codex task. Its PowerShell/conhost counts are descriptive, not component-level attribution.
• A later 26.707.9981.0 retest was run after the other user-visible task completed and still captured 26 direct ChatGPT.exe -> git.exe starts in 90.6 seconds.
• The currently selected workspace was non-Git, but Desktop may retain historical project entries, watchers, or task-directory state. The source workspace has not been proven.

Evidence before reboot

Immediately before reboot:

| Metric | Value |
|---|---:|
| Committed memory | 47.25 / 49.29 GB |
| Commit utilization | 95.9% |
| Available physical memory | 1.19 GB |
| Paged pool | 1.77 GB |
| Nonpaged pool | 2.89 GB |
| Live git.exe at snapshot time | 0 |

RAMMap Use Counts / Processes views showed:

• approximately 9.63 GB under Page Table
• 309,750 rows in the Processes view, versus roughly 340 currently live processes
• row counts grouped by the displayed Image value included:
• 188,302 git.exe
• 104,232 conhost.exe
• 6,012 cmd.exe
• 4,319 powershell.exe

Task Manager did not show one normal live user process owning the missing memory. RAMMap attributed a large amount to Page Table while evidence of high process creation/termination churn was also present. This is correlation evidence, not proof that the churn created every retained page-table byte.

A 20-second Win32_ProcessStartTrace capture immediately before reboot recorded:

• 33 git.exe starts
• 25 conhost.exe starts
• at least 17 git.exe processes directly parented by the current ChatGPT.exe
• bursts of 5–6 direct Git starts in a single second

This trace establishes Desktop-host ancestry for the direct children. It does not, by itself, distinguish automatic repository discovery from Git activity requested through another Codex task.

One surviving Git command line captured separately was:

git.exe -c core.hooksPath=NUL -c core.fsmonitor=false remote -v

The command-line observation and the later direct-parent trace were separate captures, so I am not claiming that every traced Git process used this exact command.

Clean reboot control

Approximately four minutes after reboot, with Codex running again:

| Metric | Before reboot | After reboot |
|---|---:|---:|
| Committed memory | 47.25 GB | 11.27 GB |
| Commit utilization | 95.9% | 31.0% |
| Available memory | 1.19 GB | 22.55 GB |
| Paged pool | 1.77 GB | 0.47 GB |
| Nonpaged pool | 2.89 GB | 0.49 GB |

The Windows commit limit changed from 49.29 GB to 36.33 GB after reboot because the page file is dynamically managed; the significant result is that committed memory and kernel-pool usage returned to a normal baseline.

An initial 30-second post-reboot process-start trace recorded:

• 0 git.exe starts
• committed memory remained stable around 11.2 GB
• available memory remained stable around 22.6 GB

Reproduction again after the clean reboot

A later trace remained quiet for 46 seconds with 0 Git starts. During the immediately following 12-second interval, it captured:

• 40 git.exe starts total
• 21 directly parented by the current ChatGPT.exe
• 19 additional Git children with intermediate parents
• 42 conhost.exe starts
• 18 powershell.exe starts directly parented by ChatGPT.exe
• one may have been the monitoring shell, and another Codex task may also have been active; this trace does not assign the remaining processes to one internal component
• 4 cmd.exe starts

The monitoring command did not invoke Git. Another Codex task may still have contributed activity in this early trace; the later isolated test below removes that specific confound. At the end of this interval, 2 Git processes were still live.

At that point memory had not yet returned to the critical state:

• committed memory: 12.96 / 36.33 GB (35.7%)
• available memory: 21.41 GB
• paged pool: 0.50 GB
• nonpaged pool: 0.51 GB

This shows an intermittent pattern: short observation windows may report 0 Git activity, followed immediately by a concentrated burst.

Workspace state

The currently selected workspace and two inspected ancestor directories do not contain a .git directory. A later old-version retest was performed after the other user-visible Codex task completed and still recorded 26 direct ChatGPT.exe -> git.exe starts in 90.6 seconds.

This rules out the other active user-visible task as a necessary trigger for that retest, but it does not prove that the selected non-Git directory was the source. A stored project entry, historical task directory, internal workspace cache, or background watcher may still be involved.

Isolated version comparison

The same process-start observation was repeated after updating the Store/MSIX package. Counts below are system-wide events observed in the window unless direct ChatGPT.exe ancestry is explicitly stated.

| Metric | 26.707.9981.0 | 26.727.6591.0 |
|---|---:|---:|
| Observation window | 90.6 s | 90.8 s |
| System-wide git.exe starts | 52 | 53 |
| Direct ChatGPT.exe -> git.exe | 26 | 0 |
| System-wide conhost.exe starts | 66 | 90 |
| Direct ChatGPT.exe -> powershell.exe | 15 | 11 |

The old-version window confirms 26 direct Desktop-hosted Git starts. In the new-version window, intermediate parents exited before they could be identified, so the 53 system-wide Git starts cannot all be attributed to Codex. The new-version follow-up is therefore inconclusive for Codex-specific ancestry: it does not demonstrate a fix, but it also does not prove that all observed Git/conhost activity came from Codex.

Unrelated applications were using memory during the new-version test. Absolute committed/available-memory values from that window are intentionally excluded from the causal comparison.

Steps to reproduce

1. Use Codex Desktop on Windows 11 (26.707.9981.0 confirmed direct ancestry; 26.727.6591.0 follow-up included).
2. Restart the Desktop app; for memory-baseline work, start from a clean Windows reboot.
3. Complete or pause other user-visible Codex tasks, then open one task in a local non-Git directory.
4. Run a diagnostic command that does not invoke Git.
5. Monitor process creation continuously with Win32_ProcessStartTrace, ETW, or Process Monitor for at least 60–120 seconds.
6. Record command line and complete ancestry at process-start time; follow-up WMI queries can miss very short-lived parents.
7. Separate system-wide counts from processes whose ancestry is confirmed under ChatGPT.exe.
8. If Codex is left running for a long period, monitor Windows commit, RAMMap Page Table values, and pool usage without intentionally driving the machine back to exhaustion.

Intentionally reproducing the final 95%+ commit state is unsafe because it makes the machine unusable.

Expected behavior

• A non-Git workspace should produce one failed repository detection result, not repeated subprocess bursts.
• Negative Git-root results should be cached and invalidated only by relevant filesystem/workspace changes.
• Git probing should be debounced, rate-limited, and protected by backoff and a circuit breaker.
• In-flight Git subprocess concurrency must be strictly bounded.
• Repeated failures in optional PowerShell/WMI sampling should be bounded and should not repeatedly launch cold PowerShell collectors without backoff or single-flight behavior.
• Task completion or workspace inactivity should cancel Git watchers and pending review/status work.
• Completed child processes, handles, process objects, ETW state, and captured output must be released promptly.
• Background workspace features must not drive unbounded process churn or host resource exhaustion.

Working diagnosis and limits

The evidence establishes:

1. On 26.707.9981.0, an isolated retest captured 26 direct ChatGPT.exe -> git.exe starts in 90.6 seconds.
2. Git process creation recurred after a clean reboot.
3. The long-running incident correlated with approximately 9.63 GB under RAMMap Page Table, large Processes-view row counts labeled git.exe/conhost.exe, and 95.9% Windows commit utilization.
4. Reboot cleared the accumulated memory pressure but did not remove the old-version process-creation behavior.
5. The 26.727.6591.0 system-wide counts did not fall in the sampled window, but Codex-specific Git ancestry was not recovered and remains inconclusive.

This does not by itself distinguish among retained process objects, unreleased page-table resources, ETW/WMI tracking state, handle leakage, captured subprocess output, or another Codex/Windows lifecycle defect. A maintainer ETW trace or diagnostic build would be needed to identify the exact retained resource.

Related issues

• #33450 — exact same original app version, invalid/non-Git project entries, and matching Git command family
• #32324 — sandbox helper creating invalid empty .git paths and triggering repeated Git probes
• #26812 — high-rate Git/conhost process churn and Windows kernel-pool growth in Git workspaces
• #34473 — no-backoff Git-root retries and frequent PowerShell/WMI process sampling
• #35775 — VS Code extension git-origins polling with controlled install/uninstall evidence and PID 4 Section-handle growth
• #35776 — newer Windows Desktop build exhausting system commit during repeated Git review/status work
• #36176 — broader Windows Desktop process-inventory/Git fan-out tracker with source tracing and controlled diagnostic-patch evidence

This issue may ultimately be consolidated into #35776 or #36176. Its distinct contribution is the RAMMap Page Table observation, clean-reboot memory control, intermittent old-version direct-ancestry evidence, and a carefully qualified 26.727.6591.0 follow-up. It does not claim a newly proven root cause.