Windows Desktop 26.908.4834.0: `ntfs.sys` `NtFC` nonpaged pool grows ~0.5 GB/min while Codex is open

Summary

I independently reproduced a severe Windows kernel nonpaged-pool growth problem while Codex Desktop is running.

The growth is dominated by the ntfs.sys pool tag NtFC. In my testing, the system nonpaged pool grows continuously while Codex is open and stops growing as soon as Codex is fully closed.

This appears closely related to #16786 and directionally related to #31212, but I am reporting an independent reproduction on a newer Codex Desktop build with additional PoolMon and Process Monitor evidence.

Environment

• Windows 11 x64
• cmd.exe reported OS version: 10.0.26200.9445
• RAM: ~32 GB
• Codex Desktop versions observed during troubleshooting:
  • 26.903.9818.0
  • 26.908.4834.0
• Git for Windows: 2.55.0.windows.3
• Git path: D:\Git\cmd\git.exe

Primary symptom

When Codex Desktop is open, Windows Nonpaged Pool rises continuously. When Codex is fully closed, the growth stops.

One measurement while Codex was open:

Time	Nonpaged Pool
03:46	3.2 GB
03:48	4.2 GB
03:50	5.4 GB

That is roughly +2.2 GB in 4 minutes, or around 0.5–0.6 GB/minute in that run.

GPU acceleration ruled out as the main trigger

I launched Codex with GPU acceleration disabled:

--disable-gpu --disable-gpu-compositing

The nonpaged-pool growth continued at essentially the same rate. This makes the GPU path unlikely to be the primary cause.

PoolMon evidence: NtFC dominates the growth

I used PoolMon from WDK with:

poolmon.exe /p /b

A clean-ish baseline before the Codex-triggered growth showed:

Pool N: 849352K

After starting Codex, later samples showed:

Pool N: 1132104K
NtFC Bytes: 209730528
NtFC Diff: 1872594

and then:

Pool N: 1524688K
NtFC Bytes: 602428288
NtFC Diff: 5378824

Between those two PoolMon samples:

• Total nonpaged pool increased by roughly 383 MB
• NtFC increased by roughly 375 MB

So in that interval, NtFC accounted for almost all of the pool growth.

Most importantly:

Closing Codex caused NtFC Bytes to stop increasing.

This is highly repeatable on the affected machine.

Process Monitor evidence: extremely high file-system activity from ChatGPT.exe

A short Process Monitor trace showed the Codex/ChatGPT process generating a very large number of file events.

For one ChatGPT.exe process:

PID: 25324
Started: 04:50:02
Ended:   04:50:25
File Events: 265,314
Total User CPU:   00:00:08.9843750
Total Kernel CPU: 00:00:57.5312500

That is roughly 11,500 file-system events per second over the observed interval.

The File Summary for the same capture showed approximately:

Total Events: 77,724
Opens:        76,200
Distinct file paths: 75,759

This looks much more like broad/high-frequency file enumeration than repeated access to a single file.

The folder summary showed tens of thousands of opens under paths exposed through both C: and D:. Some of those paths were later confirmed to involve Windows/MSIX junction/reparse-point mappings, so I do not want to over-interpret the apparent C-vs-D split. The important point is the very high number of distinct file opens while Codex is active.

Git activity is definitely involved

Short-lived Git processes were initially easy to miss with polling, but Windows process-start tracing and Procmon confirmed that Codex does spawn git.exe.

One captured command was:

D:\Git\cmd\git.exe \
  -c safe.bareRepository=explicit \
  -c core.hooksPath=NUL \
  -c core.fsmonitor= \
  rev-parse --path-format=absolute --show-toplevel --git-common-dir

The corresponding Git for Windows execution layer also appeared as:

D:\Git\mingw64\bin\git.exe

A process-start trace also showed very short-lived git.exe parent/child activity associated with the Codex process tree.

I have not yet captured the exact high-volume Git command that explains the file enumeration in this reproduction. In particular, I have not yet confirmed the exact git ls-files --others --exclude-standard -z command reported in #16786. So I do not want to overstate that part.

What is confirmed on this machine is:

1. Codex is the repeatable user-mode trigger.
2. Codex performs very high-volume file-system activity.
3. Codex launches Git processes.
4. ntfs.sys NtFC grows rapidly while Codex is active.
5. Closing Codex stops the NtFC growth.

Reproduction / diagnostic sequence

1. Reboot Windows to establish a clean baseline.

2. Start PoolMon:

   poolmon.exe /p /b
   

3. Note the initial Pool N and NtFC values.

4. Launch Codex Desktop normally.

5. Observe NtFC Bytes and total nonpaged pool increasing continuously.

6. Optionally run Procmon for 10–30 seconds with File System Activity enabled.

7. Observe ChatGPT.exe producing very high file-event counts and many distinct file opens.

8. Fully close Codex.

9. Observe that NtFC stops increasing.

The behavior also reproduced when Codex was launched with GPU acceleration disabled.

Separate issue discovered during troubleshooting: non-system AppX volume

During diagnosis I also found a separate Codex Desktop startup issue:

• When the Codex MSIX package was physically located on a non-system AppX volume (D:\WindowsApps), Codex started background processes (ChatGPT.exe, GPU process, Network Service, Storage Service), but no --type=renderer process appeared and no GUI window opened.
• Moving the Codex AppX package back to the system AppX volume on C: immediately restored the GUI.

This appears to be a separate issue from the nonpaged-pool leak, but I am including it because it complicated the reproduction process.

After the GUI was restored on C:, the NtFC leak immediately reproduced again.

Expected behavior

• Codex Desktop should not cause unbounded ntfs.sys NtFC nonpaged-pool growth.
• Background repository/status scanning should be scoped to the active workspace and should be bounded/debounced/cached.
• Codex should avoid creating a workload that drives hundreds of thousands of file operations in a few seconds during normal background activity.
• If Git-based workspace discovery/status checks are responsible, they should not run in a tight or unbounded loop.

What I ruled out

• GPU acceleration as the primary trigger: disabling GPU did not stop the leak.
• Normal user-mode process memory leak: the dominant growth is in Windows nonpaged pool and specifically NtFC.
• A one-off observation: the start/stop relationship with Codex was reproduced multiple times.
• The .codex data-directory relocation itself: restoring the original local .codex directory did not change the behavior.

Related issues

• #16786 — Windows app repeatedly spawns Git scans and ntfs.sys NtFC grows continuously
• #31212 — sustained Windows kernel pool growth during Codex Desktop activity

This independent reproduction strongly suggests that the Windows NtFC problem is still present in newer Codex Desktop builds.

I can provide additional artifacts if useful, including:

• PoolMon screenshots showing NtFC growth
• Procmon Process Activity Summary / File Summary screenshots
• Git Process Create captures and command lines
• AppX/MSIX volume and junction diagnostics

Start by reproducing the issue with PoolMon using poolmon.exe /p /b, then capture Codex activity in Process Monitor and process-start tracing. Trace the confirmed Git invocations and high-volume file events to the workspace or repository scanning entry point; no source file or test is named in the report. Done means normal Codex activity no longer causes unbounded NtFC growth or sustained file-operation bursts, including with GPU acceleration disabled.