Windows Codex Desktop appears to trigger sustained kernel pool growth via file/pipe/filter-driver activity

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

• #30389
• #30926
• #30512
• #30992

Powered by Codex Action

Follow-up: current Codex build, ETW process storm, and live kernel object ownership

I reproduced the same failure mode on a current Codex Desktop build and collected additional ETW, PoolMon, and live-kernel-dump evidence.

Environment

• Windows 11 Home 25H2, build 26200.8655, x64
• 32 GB RAM, AMD Ryzen 9 7845HX
• Codex Desktop package OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
• Git for Windows 2.55.0.windows.2
• Kaspersky for Windows 21.23.6.614

Codex-triggered process churn

During a 35-second WPR/ETW process trace, there were 846 new processes:

git.exe         526
conhost.exe     291
powershell.exe   28
wpr.exe           1

The trace contained 263 direct ChatGPT.exe -> git.exe starts. (ChatGPT.exe is the desktop process image in this Codex package.) The dominant repeated command was:

"C:\Program Files\Git\cmd\git.exe" -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel

The selected workspace root contained an empty .git directory with no HEAD. Renaming that directory out of the workspace stopped the Git storm in subsequent samples (git.exe count remained zero). This is consistent with #29110, #28631, and #26812: a failed repository-root probe appears to be retried without effective negative-result caching or backoff.

Exited process objects were retained

Stopping the Git storm prevented the catastrophic creation rate, but did not reclaim objects already retained during that boot. At approximately 45 minutes uptime, with only 245 active processes and zero live git.exe processes, PoolMon showed:

Tag   Allocs   Frees   Diff    Bytes
Proc  54,424       1  54,423  195,052,464
MiP2  54,425       1  54,424   83,595,264
PsIn 571,486 517,062  54,424    8,233,440

A reboot reclaimed the accumulated pool. With the empty .git mitigation still in place:

• At 78 minutes uptime: Proc Diff=1,367, Frees=1, zero git.exe.
• At 111 minutes uptime: Proc Diff=2,187, Frees=3, zero git.exe.

This reduced the growth rate by roughly 98%, but process-object frees still remained close to zero, so the retention path was mitigated rather than fully resolved.

Live kernel dump: sampled holder was Kaspersky

A live kernel dump captured one exited git.exe process object created by ChatGPT.exe. Debugger analysis showed:

• The exited process object still had two external handles.
• !findhandle found both handles in Kaspersky's avp.exe.
• !obtrace included Kaspersky process-notify/filter stacks involving arkmon, klflt, klgse, and klif.
• Across all reference tags, the sampled object had three net outstanding references.

The large +32768 value visible in the object trace is Windows process-object reference bias, not 32,768 leaked references. The sampled evidence proves that avp.exe was the immediate external handle holder for this exited process object at capture time. It does not prove that Kaspersky permanently leaks every object, or that Kaspersky alone is the root cause.

The evidence supports an interaction model:

1. Codex generates an abnormal volume of short-lived Git/console processes when repository discovery loops.
2. Security/filter software inspects those processes and temporarily opens protected process handles.
3. Closure lag or backlog retains exited Windows process objects and their Proc/MiP2/PsIn allocations.
4. Windows cannot reclaim those objects while external handles or references remain.

After adding narrow Kaspersky trusted-application rules, a controlled run of 64 immediate-exit cmd.exe children still produced Proc AllocDelta=145, FreeDelta=0; Kaspersky's Process-type handle count increased by only 7. The rules reduced the workload but did not restore timely reclamation.

Requested fix and diagnostics

Please investigate the Windows desktop repository-discovery loop and:

• Cache a negative repository-root result and apply retry backoff.
• Treat an empty/invalid .git directory as a bounded error instead of continuously spawning git.exe.
• Debounce and deduplicate identical rev-parse --show-toplevel requests per workspace.
• Rate-limit or reuse short-lived shell/Git subprocesses on Windows.
• Add diagnostics exposing the refresh trigger, command category, workspace-path hash, retry count, and in-flight deduplication state.
• Consider a user-facing switch to disable automatic Git metadata polling as an emergency workaround.

This evidence also connects the Git/process reports in #26812, #29110, and #30926 with the Kaspersky interaction reported in #17955. It suggests a cross-product amplification path rather than a simple user-mode heap leak or a single-vendor failure.

I have a 3.6 GB live kernel dump plus sanitized PoolMon, ETW, and debugger summaries. I will not attach the raw dump publicly because it may contain sensitive kernel memory, but I can provide selected sanitized artifacts or use a private upload channel if an OpenAI maintainer requests them.

Additional reproduction: Browser/CUA runtime mitigation stopped observed pool growth

I reproduced the kernel-pool growth on Windows with the current Desktop package:

• Codex Desktop: OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
• Before reboot:
• Paged Pool: 7.174 GB
• Nonpaged Pool: 1.200 GB
• Committed: 24.007 GB
• Available: 13.563 GB
• The demonstrated Codex process tree itself accounted for only about 1.2 GB working set, consistent with the retained memory being kernel pool rather than normal process-private memory.

A reboot reclaimed the accumulated pool:

• Paged Pool: 0.475 GB
• Nonpaged Pool: 0.506 GB
• Committed: 12.623 GB
• Available: 21.238 GB

Additional local observation

The Codex configuration had:

• browser@openai-bundled installed and enabled
• three live node_repl.exe processes
• native-pipe settings including SKY_CUA_NATIVE_PIPE=1
• a turn-ended notify hook launching codex-computer-use.exe

Simply editing generated config.toml entries was not persistent: Codex recreated the file at the next startup and re-injected the Browser/node_repl configuration.

The persistent mitigation used was:

codex plugin remove browser@openai-bundled
codex mcp remove node_repl
codex features disable browser_use
codex features disable browser_use_external
codex features disable browser_use_full_cdp_access
codex features disable computer_use
codex features disable in_app_browser

I also removed the generated turn-ended notify entry and terminated only the three Codex-runtime node_repl.exe processes.

Verification after mitigation:

• browser@openai-bundled: not installed
• node_repl.exe: 0
• codex-computer-use.exe: 0
• Paged Pool over 10 seconds: 0.496 -> 0.497 GB (+0.2 MB)
• Nonpaged Pool over 10 seconds: 0.468 -> 0.466 GB (-2.2 MB)
• The user also observed that the pool stopped continuously increasing.

No Microsoft Defender exclusion was added.

This is a short observation window and does not prove that Browser/CUA is the sole cause. The workspace still contains an empty/invalid .git directory, so the repository-discovery behavior described in the other follow-up remains a possible concurrent trigger. However, the result suggests that Browser/CUA node_repl native-pipe activity and the per-turn codex-computer-use.exe hook are worth isolating in a controlled reproduction.

It may also be useful for Codex to avoid silently re-injecting removed generated MCP/notify configuration, or to expose a single supported “safe mode” that disables Browser/CUA runtimes and high-churn background tooling while diagnosing Windows pool growth.

I am seeing what appears to be the same issue on Windows 11.

In-app Codex feedback session ID:
019ee25c-ca99-7c93-b434-1997d09c7386

Environment:

• Windows 11
• 32 GB RAM
• Codex Desktop
• ChatGPT Classic also installed
• F-Secure Endpoint Protection
• F-Secure VPN tested with Hydra and WireGuard
• OneDrive used for the main Codex project workspace

Observed behavior:

• During extended Codex use, RAM usage rises toward 90–98%.
• Task Manager does not show any single user-mode process consuming the memory.
• RAMMap shows the retained memory at kernel level.
• In bad state, I have observed:
• Page Table approximately 8.5–9.9 GB
• Nonpaged Pool approximately 2.7–3.1 GB
• Paged Pool approximately 2.1–2.8 GB
• Closing Codex does not reliably release the already accumulated kernel memory.
• Reboot is required to recover.

Controlled observations:

• ChatGPT Classic alone stayed stable.
• Codex active with OneDrive closed still caused CommittedMB and kernel pools to grow.
• OneDrive significantly worsened the growth, but was not the only trigger.
• git.exe was not active during later growth tests, so Git is not the sole cause.
• Earlier, broken empty .git folders in the OneDrive workspace caused repeated git.exe rev-parse / core.fsmonitor polling, but memory growth also occurs without git.exe running.

Example measurement with Codex active and OneDrive closed:

• AvailableMB: 9657 -> 9474
• PoolNonpagedMB: 1979.5 -> 1996.3
• PoolPagedMB: 1893.4 -> 1923.7
• CommittedMB: 25579.9 -> 25972.5
• OneDriveWorkingMB: 0 throughout

Example measurement after stopping Codex / ChatGPT / OneDrive:

• AvailableMB stabilized
• CommittedMB stabilized
• PoolNonpagedMB and PoolPagedMB stopped growing

This looks consistent with the issue described here: Codex appears to trigger Windows kernel memory / pool growth. In my case OneDrive and endpoint protection may amplify the issue, but Codex appears to be the repeatable trigger.

I can reproduce a very similar issue on Windows, and I collected both PoolMon data and a targeted WPR trace.

System details:

• Windows 11, build 26100
• 32 GB physical RAM
• Codex Desktop package: OpenAI.Codex_26.707.9564.0_x64
• Main executable: ChatGPT.exe
• AMD RX 7900 XTX, driver 32.0.31021.5001
• Only one physical GPU is active; there is no active iGPU
• Huorong Security is installed, with sysdiag.sys version 6.0.0.3

At the time of diagnosis:

• Memory usage reached approximately 88%
• System commit was approximately 42.5 GB
• Paged pool was over 8 GB
• Nonpaged pool was approximately 4–5 GB
• Normal user-mode process memory did not account for this usage

The largest PoolMon tags included:

• FMfn: 4,292.67 MiB
• File: 1,658.58 MiB
• Ntfc: 659.58 MiB
• IoNm: 593.96 MiB
• IoFE: 576.68 MiB
• SQSF: 440.14 MiB

Over a 36.82-minute PoolMon interval, FMfn increased by 68.26 MiB, or approximately 1.85 MiB/minute.

I then captured a targeted 155-second WPR trace containing allocation and free stacks for FMfn. The resulting ETL was only 207 MiB.

The trace contained:

• 82,218 pool events
• 0 malformed events
• 40,471 paged FMfn allocations
• 22,854 paged FMfn frees
• Net paged FMfn growth: +6.607 MiB

The most significant finding was extreme Git process churn:

• 3,047 git.exe process lifetimes in approximately 155 seconds
• 1,508 were directly parented by the Codex ChatGPT.exe process
• This is approximately 9.7 directly spawned Git processes per second

The most frequent commands were:

• 1,933 × rev-parse --show-toplevel
• 642 × config --null --get core.fsmonitor
• Repeated status, read-tree, ls-files, and related repository queries

Representative allocation stacks included:

CreateFileW
  -> fltMgr
  -> sysdiag.sys
  -> normalized file-name query
  -> bfs.sys
  -> FltpAllocateFileNameInformation (FMfn)

and:

git.exe
  -> GetFileAttributesW
  -> fltMgr
  -> bindflt.sys!BfGetPreCreateFileName
  -> FltpAllocateFileNameInformation (FMfn)

Within the top 100 outstanding stack groups:

• 56.4% of the represented outstanding bytes contained sysdiag.sys
• 71.4% contained bindflt.sys
• 68.7% contained bfs.sys

These categories overlap because several filters appear in the same call path. This does not prove that Huorong is solely responsible, but it strongly suggests that Codex’s abnormal Git/file-query workload is being amplified or retained by the Windows minifilter stack.

I did not find evidence that the GPU was the primary source. During the same 36.82-minute interval:

• 003D: 0 MiB growth
• DAL3: +1.70 MiB
• Vi54: +1.00 MiB

Could the Codex team investigate why the desktop app is launching thousands of short-lived Git probes and whether repository-state polling can be debounced, cached, or disabled? On this machine, the Git process storm appears to be the workload trigger, while the file-filter stack is where the kernel-pool allocations accumulate.

I can provide sanitized PoolMon snapshots and stack reports. The raw ETL contains local paths and command lines, so I would prefer not to upload it publicly.

Follow-up: current Windows build, NtFC allocations map almost 1:1 to minifilter failures and all outstanding stacks include bindflt.sys

I reproduced the same kernel-pool growth on a newer Codex Desktop build and collected a focused WPR Pool + Minifilter trace. This reproduction is especially concentrated in the nonpaged NtFC tag.

Environment

• Codex Desktop (Microsoft Store): OpenAI.Codex_26.715.4045.0_x64
• Main desktop image: ChatGPT.exe
• Windows 11 Home 25H2, build 26200.8875, x64
• Physical memory: approximately 64 GB
• bindflt.sys: 10.0.26100.8655
• CPU: AMD Ryzen 9 9955HX3D
• GPUs:
• AMD Radeon 610M, driver 32.0.21032.8002
• NVIDIA RTX 5090 Laptop GPU, driver 32.0.16.1047

User impact and live growth

Before reboot, nonpaged pool reached approximately 52.7 GB. Normal user-mode process memory did not account for it.

After reboot and reopening Codex Desktop, an 11-second counter sample showed:

Nonpaged pool: 3.394 GB -> 3.498 GB
Growth:        106.8 MB in 11 seconds
Rate:          10.59 MB/s

The CLI was present during the same session but idle; the active Codex Desktop ChatGPT.exe process was the workload correlated with the growth.

WPR capture

The trace was collected with:

wpr -start Pool -start Minifilter -filemode
# reproduce briefly
wpr -stop Codex-NtFC.etl

Trace summary:

Duration:                 ~38 seconds
Total events:             42,740,771
Events lost:              0
PoolAllocation events:     5,635,321
PoolFree events:           5,491,123
Minifilter PreOpInit:      1,683,804
Minifilter PreOpFailure:     128,626
FileIO Create:               258,060
FileIO Cleanup:                  530
FileIO Close:                    498

NtFC ownership

The focused pool-event parser found:

NtFC events:                         143,536
Outstanding NtFC allocations:       128,636

Codex Desktop main ChatGPT.exe:
  Allocations:                      128,778
  Frees:                                144
  Net outstanding count:           128,634
  Net outstanding bytes:        18,523,296

Therefore, 128,634 of 128,636 outstanding NtFC allocations created during the trace were attributed to the Codex Desktop main process.

The 128,626 Minifilter PreOpFailure events are almost a one-to-one match with the 128,634 outstanding Codex-attributed NtFC allocations.

Stack evidence

The ETL was converted to ETLX and all 128,636 outstanding NtFC allocations were inspected with call stacks.

Every outstanding allocation stack contained:

ntoskrnl.exe
ntfs.sys
fltmgr.sys
bindflt.sys
ntdll.dll
kernelbase.dll
kernel32.dll
chrome.dll

The common file-filter chain was:

ntfs.sys -> fltmgr.sys -> bindflt.sys
128,636 outstanding allocations
18,523,584 bytes represented
100% of outstanding NtFC allocations

Notably, none of the outstanding NtFC stacks contained:

• WdFilter.sys
• bfs.sys
• CldFlt.sys
• AMD or NVIDIA display-driver modules

This does not prove that bindflt.sys alone is the root cause. It does show that, in this reproduction, Codex Desktop's Chromium/main-process file activity is the repeatable trigger and the retained NtFC allocations all pass through the Windows Bind Filter path.

Unsafe diagnostic result: unloading bindflt caused a bugcheck

As a diagnostic only, fltmc unload bindflt was attempted. The system immediately became unstable and restarted with:

Bugcheck: 0x0000003B SYSTEM_SERVICE_EXCEPTION
Exception: 0xC0000005
Dump: C:\Windows\Minidump\071826-17921-01.dmp

After reboot, bindflt returned to its normal RUNNING / AUTO_START state.

I do not recommend unloading or disabling bindflt as a workaround. I am including this only because it further indicates active dependency on this filter path and because maintainers should avoid suggesting that mitigation.

Requested investigation

Please investigate:

1. Why the Codex Desktop main process generates approximately 128k minifilter pre-operation failures in under 40 seconds.
2. Whether a failed file/open/path-resolution operation is being retried without effective caching, deduplication, or backoff.
3. Whether packaged-app path mapping through bindflt.sys exposes a lifecycle bug that is not triggered by the CLI.
4. Whether Codex can detect this sustained kernel-pool growth and stop/restart the offending file-query loop before system memory is exhausted.
5. Whether a supported diagnostic or safe mode can disable high-churn desktop background file probing without modifying Windows filter drivers.

Diagnostic artifacts

Available locally:

• Raw WPR ETL: approximately 2.5 GB
• Generated ETLX: approximately 6.1 GB
• Minidump: approximately 7.3 MB
• Sanitized allocation/count/stack summaries

I have not uploaded the raw ETL or dump publicly because they may contain local paths or process memory. I can provide sanitized summaries or use a private upload channel if requested.