Windows app repeatedly spawns \git ls-files --others --exclude-standard -z`; `ntfs.sys` `NtFC` nonpaged pool grows continuously`

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

• #15620
• #15868
• #16374

Powered by Codex Action

I have another Windows Desktop data point that looks related to this issue, although the dominant pool tags are different on my machine.

Environment:

• Codex Desktop package: OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0
• Windows: build 26200 x64
• GPU: AMD Radeon 780M
• AMD display driver after update: 32.0.31021.5001 (amdkmdag.sys)

Observed behavior:

• After reboot + AMD/Windows updates, the earlier severe pool stock was cleared, but nonpaged pool still grows when Codex Desktop is open.
• While Codex was closed for a while, nonpaged pool did not noticeably rise. After reopening Codex, File/IoFE growth resumed.
• This does not look like a normal user-mode handle leak; process handle counts are modest compared with the kernel pool-object growth.

PoolMon / A-B evidence:

• After reopening Codex, current PoolMon showed roughly:
• File ~270 MB
• IoFE ~91 MB
• SQSF participated earlier but is a Storage QoS amplifier, not the root cause
• storqosflt.sys A/B test:
• stopping storqosflt released SQSF from 37.42 MB to 0 MB
• during the same 5-minute stopped window, File still grew by +15.38 MB
• IoFE still grew by +5.53 MB
• conclusion: Storage QoS amplifies/tracks the path, but does not cause the underlying File/IoFE growth.

WPR/WPA evidence from an elevated trace:

• Administrator WPR trace generated a 29 GB ETL; WPA Pool Graph export showed:

Tag   impacting rows   amdkmdag.sys rows   chrome.dll rows   Codex.exe rows
File  5,429            5,017               863               165
IoFE  10,307           9,854               1,720             316
SQSF  2,508            31                  13                73

Representative interpretation:

• The dominant File/IoFE stack family goes through amdkmdag.sys.
• Codex.exe / Chromium (chrome.dll) stacks are present in the same File/IoFE trace.
• This matches the runtime observation: closed Codex = no obvious growth; reopened Codex = growth resumes.

Disk I/O evidence during the trace:

• codex.exe <OpenAI.Codex> generated 7,177 disk I/O rows.
• The hottest paths were:
• %USERPROFILE%\.codex\logs_2.sqlite - 6,234 rows
• %USERPROFILE%\.codex\logs_2.sqlite-wal - 1,327 rows
• Codex package cache / Chromium cache paths under the Codex app package

Current working hypothesis:

• This appears to be the same broad class of Windows kernel nonpaged-pool pressure triggered by Codex Desktop background activity.
• On my machine the strongest chain is:

Codex Desktop / Electron / Chromium activity
especially high-frequency .codex logs_2.sqlite + WAL writes and Chromium/GPU activity
-> AMD graphics driver path (amdkmdag.sys)
-> Windows File / IoFE nonpaged pool growth
-> storqosflt/SQSF as a secondary amplifier

So while my dominant tags are File/IoFE rather than NtFC, this looks directionally related: Codex Desktop user-mode activity is the reproducible trigger for continuously growing Windows kernel nonpaged pool. Happy to provide more exact PoolMon/WPA summaries if useful; the raw ETL is large (~29 GB).

I have this exact problem

me 2

Independent reproduction on a newer Windows desktop build

I independently reproduced the same severe Windows nonpaged-pool growth on 2026-07-20. I have not yet verified the exact repeated git.exe command line on this machine, but the A/B behavior and dominant NtFC pool tag closely match this issue.

Environment

• Desktop package: OpenAI.Codex 26.715.4045.0 x64 (new unified ChatGPT/Codex desktop app; UI is labeled ChatGPT)
• Windows 11 Home 25H2 x64, OS build 26200.8875
• RAM: 64 GB

Controlled closed → open → closed sampling

Memory counters were sampled every 5 seconds.

• App closed for ~2 minutes: system nonpaged pool stayed within 1275.8–1281.4 MB
• App open for 10m31s: system nonpaged pool increased from 1394.2 MB to 6483.3 MB (+5089.1 MB)
• Linear growth rate during the open phase: approximately 478.7 MB/min, with R² = 0.999685
• App private memory did not grow with it: 1750.9 MB → 1717.9 MB
• App process-level nonpaged pool remained approximately 0.28 MB
• System paged pool remained roughly stable around 1.72–1.75 GB
• After all ChatGPT/Codex processes exited (ProcessCount = 0), system nonpaged pool was 7684.4 MB and remained 7684.7 MB about 5 minutes later, so the accumulated pool was not meaningfully released

Separate PoolMon reproduction

System nonpaged pool (Pool N) increased as follows:

• 23:50:59: 687,464 K
• 23:55:15: 3,326,668 K
• 23:56:28: 4,046,564 K

At 23:55:15, the dominant entry was:

Tag: NtFC
Type: Nonp
Allocs: 16,208,414
Frees: 14,968
Diff: 16,193,446
Bytes: 2,331,856,224
Per Alloc: 144
Mapped driver: ntfs.sys - Create.c

For comparison, NVRM was only about 67,096,576 bytes in the same sample, so the NVIDIA pool tag was not the dominant source.

This confirms that the issue still reproduces on package version 26.715.4045.0, with the desktop app acting as a reliable user-mode trigger for rapid NtFC / ntfs.sys nonpaged-pool growth. I have the CSV time series and PoolMon screenshots available if maintainers need the raw artifacts.

The repeated git ls-files --others loop in this report is the same class of Git-backed refresh workload 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.

I triggered this runaway memory leak on myself by making my home dir a git repo (%USERPROFILE%\.git) months ago for forgotten reasons (probably to track dot-file customisation).

• Codex treats entire profile as a repository
• repeated full-profile git ls-files scans with 350 GB in 1.2 million untracked files (thank-you APPDATA and synced OneDrive)
• Windows NTFS NtFC leak
• nonpaged-pool exhaustion

Additional reproduction on Codex Windows 26.727.6591.0 (severe regression)

I am seeing the same Codex-triggered untracked-file scan pattern on a current Windows build, with enough memory growth to freeze the whole machine.

Environment

• Codex desktop app: OpenAI.Codex_26.727.6591.0_x64
• Windows 11 Home x64, version/build 10.0.26200
• Git for Windows: 2.53.0.windows.1
• Native Windows / PowerShell agent
• Local Git repository (repository name, username, and local paths intentionally omitted)

Observed command

Codex spawns four concurrent copies of this command without an explicit Git request:

git.exe -c core.quotepath=false -c safe.directory=* -c core.fsmonitor=false ls-files --others --exclude-standard --full-name :/

Impact and frequency

• More than five incidents during the last three days.
• Two incidents on 2026-08-03 alone.
• In one measured incident, the four matching git.exe processes each consumed approximately 2,560–2,973 MB, about 11 GB total.
• Windows subsequently reported low virtual-memory/pagefile pressure, the Codex app became unresponsive, and the machine/UI fully froze, interrupting active work.
• The system-managed pagefile was enabled (about 17 GB allocated), so this was not a disabled-pagefile configuration.
• Normal Codex app exit caused all four child scans to disappear and recovered about 11.8 GB of available RAM.
• After restarting the same app version, the scans initially stayed at zero but were recreated following later ordinary workspace/thread activity. In a later recurrence, four copies were already at roughly 507–602 MB each when detected.
• This started after the 26.727 app update; there had been no comparable incident in roughly the preceding 30 days.

Why this appears app-side

• No user-requested Git operation launched these commands.
• The four commands are identical and run concurrently against the same workspace.
• They disappear with a normal Codex app exit and recur after later Codex workspace/thread activity.
• During one affected checkpoint attempt, the actual test body/pytest process had not started, so the task payload itself was not the process creating the memory pressure.
• Delayed pushing/sharing of Git commits does not explain four identical concurrent scans.

Expected behavior

Codex should single-flight/debounce untracked-file discovery per workspace, cancel superseded scans, and impose bounded memory/time/concurrency limits. A large working tree may make one scan expensive, but it should not result in four identical unbounded scans that can freeze Windows.

It would also help to provide either:

1. an app setting to disable or defer automatic untracked-file scanning,
2. incremental/cached discovery instead of full rescans on ordinary thread activity, and
3. a visible warning/circuit breaker before duplicate Git children exhaust system memory.

No repository contents, session transcripts, or unredacted local paths are attached publicly. Sanitized process snapshots or Windows event details can be provided if maintainers request them.

I can reproduce what appears to be the same NtFC/nonpaged-pool growth on a current Codex/ChatGPT Windows desktop build.

Environment:

• Windows 11 Pro 24H2, OS build 26100.9168
• ChatGPT powered by Codex & OWL, version 26.810.52044 (released Aug 14, 2026; app reports up to date)
• 64 GB RAM

Observed behavior:

• After longer Codex repository sessions, Task Manager showed 23.6 GB non-paged pool.
• PoolMon showed NtFC Nonp at 22,408,235,776 bytes (~20.9 GiB), with a Diff/outstanding allocation count of 68,789,554 and ~325 bytes per allocation.
• Reboot clears the accumulated kernel memory.
• This has reproduced across multiple sessions/reboots.
• Closing Codex stops the continuing growth, but the already accumulated kernel pool does not reliably return until reboot.

Defender test:

• I temporarily excluded only the active Luna repository from Microsoft Defender real-time scanning.
• The problem still reproduced and non-paged pool ultimately reached 23.6 GB, so that narrow repository exclusion did not resolve it.
• The exclusion has since been removed.

Controlled reproduction with the app's built-in Performance Trace:

1. Rebooted Windows.
2. Started a ChatGPT/Codex Performance Trace.
3. Baseline non-paged pool: 816 MB.
4. Asked Codex to perform a read-only recursive audit of the repository (source, config, scripts, tests, checkpoints, documentation, agent files), deliberately creating a filesystem-heavy workload without modifying files.
5. Non-paged pool rose 816 MB -> 1.0 GB -> 1.4 GB during the recorded workload.
6. Stopped and uploaded the trace.

Uploaded performance trace / Feedback ID (as displayed by the app):
019f06df-f34a-7c02-a79b-24008e4f45f8

This looks closely aligned with the original report: sustained Codex repository/file activity correlates with rapid growth of ntfs.sys pool tag NtFC, while ordinary user-mode process memory does not account for the retained RAM. The issue remains present on version 26.810.52044.

@codex Let's resolve this issue.