Windows desktop app triggers persistent kernel-pool growth and system-wide slowdown

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

• #28980

Powered by Codex Action

I have exact same problem. Kernel memory grows to using 50Gig plus of Committed Kernel memory when the system only has 32Gig and apps only use 8Gig. At 50Gig system locks up and becomes unresponsive. I suspect this is related to how Codex uses the GPU driver because that is the only Kernel space related task I can imagine it using. My home machine with RTX3070 exhibits the issue while my work machine on a VM with no GPU has no issue both on same version listed above.

Potential duplicates detected. Please review them and close your issue if it is a duplicate. * Codex Desktop 26.616 on Windows: old sessions still missing and RAM grows to 99% of 32 GB after idle #28980 _Powered by Codex Action_

Not the same as this one is specific to Kernel Committed memory which is not released when Codex is closed. Only reboot solves it and if allowed to gobble up too much memory only a hard reset can clear it as it freezes the machine completely.

same problem

Thanks for writing this up. I am seeing a related Windows Codex Desktop performance regression in #28855: since June 12, opening/using Codex Desktop can cause severe intermittent mouse/typing/system input lag, and it still persists for me on OpenAI.Codex 26.616.10790.0.

I linked your report in a broader Discussion collecting recent Windows Desktop performance reports here: https://github.com/openai/codex/discussions/29949#discussioncomment-17428007

No action needed from you unless you want to add more detail there, but I wanted to connect the reports because the recent Windows issues look related enough that they may need a canonical tracker.

Same, I deleted all potential candidate programs, but finally it turned out that codex was a culprit. It keeps calling git.exe and making kernel level memory occupation. And Paged pool & Nonpaged pool is keep increasing.

Codex Desktop repeatedly spawned git.exe:
109 git.exe observed in 30s.
Commands included rev-parse --show-toplevel, status --porcelain, core.fsmonitor.
Paged Pool resident reached ~3.8GB, Nonpaged Pool ~1.4GB.
Earlier xperf showed SepDuplicateToken / Toke / SeAt allocations during Git process creation.
Restarting Codex did not reclaim accumulated kernel pool; reboot required.

Yes, this.. It makes Codex near unusable for more than an hour sustained. Anyone else would categorize this as a blocker level bug, how has this been open for several weeks? We literally have to reboot our machines to recover the memory, systems go into swap. You are quite possibly responsible for significantly burning through write lifetimes on people's SSDs.

Additional independent reproduction on Windows:

• Codex Windows Store package: OpenAI.Codex 26.721.4979.0
• Windows 11 Home, build 26200
• Intel Core Ultra 9 285K, 64 GB RAM, Radeon RX 9070 XT
• Symptoms: after sustained Codex use, Windows becomes progressively laggy; mouse movement stutters; video playback and games become difficult or unusable; restarting Windows clears the condition.

Controlled observations:

1. After a clean reboot, the NTFS-related nonpaged-pool tag (NtFC) started near zero and began increasing while Codex Desktop was open.
2. In a short post-reboot monitor, NtFC increased from approximately 0.44 GB to 0.76 GB while Codex processes were active. After Codex processes dropped to zero, NtFC remained stable for the next several minutes.
3. OneDrive was disabled and its sync process was absent during the test.
4. Temporarily disabling Defender real-time protection, unloading the Bitdefender filesystem filter, unloading the Windows Cloud Files filter, and disabling all three together did not stop the short-term growth.
5. A longer run previously reached approximately 20 GB of nonpaged-pool usage, and a Windows restart was required to recover the system.

The machine has 64 GB RAM and the issue is not ordinary Codex process memory: available RAM remained healthy during the controlled tests while kernel nonpaged-pool memory continued to grow.

The local Windows AppX deployment log also shows four Codex package transitions in roughly 36 hours:
26.715.9757.0 -> 26.715.10079.0 -> 26.721.3404.0 -> 26.721.3996.0 -> 26.721.4979.0.

This appears to be an independent reproduction of the kernel-pool/system-wide slowdown described here. Please consider whether the behavior persists in the current 26.721.x builds and whether Git/process/file-system activity in the Windows desktop app is involved. I can provide additional sanitized measurements if needed.

Follow-up to my earlier Windows reproduction: I found a local Git configuration that appears to be a strong trigger/amplifier.

Finding

There was a stray C:\Users\kevin\.git directory, so the entire Windows user profile was being treated as a Git working tree. While Codex Desktop was active, ChatGPT.exe repeatedly spawned git.exe commands equivalent to:

git -c core.hooksPath=NUL -c core.fsmonitor= ls-files --others --exclude-standard -z -- ...

The path list included broad profile folders such as AppData, Documents, Downloads, OneDrive, .codex, .docker, .ollama, and node_modules.

This was not a normal Git worktree setup; there was no .git\worktrees metadata. I reversibly disabled the repository root by renaming only C:\Users\kevin\.git\HEAD (the rest of the folder was retained). After that, git -C C:\Users\kevin rev-parse --show-toplevel correctly failed, and the broad profile scan stopped.

Follow-up monitor after the change

A 3.48-hour sample at 30-second intervals while Codex Desktop remained in normal use:

• Available RAM: 43.70 GB -> 46.89 GB (range 41.99-47.27 GB)
• Nonpaged pool: 2.449 GB -> 2.477 GB (range 2.387-2.701 GB)
• git.exe: no sustained activity; brief sampled maximum of 2, final count 0

This is materially different from the earlier runaway condition on this machine, where nonpaged pool grew into tens of GB and the desktop became unusable.

This does not prove that the Codex Desktop kernel-pool issue is fixed, or that every report has the same cause. It does suggest that Codex's Git/root detection can turn an accidental profile-wide Git root into very broad filesystem scanning, which may amplify the Windows Git/process/kernel-resource issue reported by others here.

Possible defensive behavior for Codex Desktop:

• avoid treating a user profile as an ordinary project root without an explicit user selection;
• detect and back off from unusually broad Git roots;
• cache failed/invalid Git-root probes and rate-limit repeated git.exe launches;
• expose Git probe rate and selected repository root in diagnostics.

I reproduced what appears to be the same persistent kernel-pool growth on a newer Codex Desktop build, and collected PoolMon data that may help identify the affected Windows components.

Environment

• Codex Desktop package: OpenAI.Codex_26.721.11231.0_x64
• Windows 11 x64
• Native Windows/PowerShell agent environment
• 64 GB RAM
• Docker Desktop service was stopped
• Workload involved prolonged Codex use, including sandboxed repository work
• Uptime when the severe slowdown was diagnosed: approximately 75 hours

Symptoms

The entire computer had become progressively slow, rather than only the Codex UI. At diagnosis:

• System process handles: 1,756,881
• Paged kernel pool: 7.82 GB
• Nonpaged kernel pool: 4.87 GB
• Committed memory: approximately 69–75 GB
• Commit limit: 86.7 GB
• Memory compression working set: approximately 4.3 GB

Disk utilization was low, the system SSD reported healthy, and closing ordinary applications did not explain the accumulated kernel usage.

PoolMon results before reboot

Largest relevant tags included:

| Tag | Type | Outstanding | Bytes | PoolMon mapping |
|---|---:|---:|---:|---|
| FMfn | Paged | 4,548,443 | 2,592,351,824 | fltmgr.sys name-cache nodes |
| File | Nonpaged | 1,911,532 | 764,297,152 | File objects |
| WCsc | Nonpaged | 1,745,606 | 670,312,704 | Confirmed present in wcifs.sys |
| IoNm | Paged | 1,839,502 | 591,376,880 | I/O name parsing |
| WCri | Paged | 1,023,494 | 529,270,848 | Wcifs-related tag |
| FMfc | Nonpaged | 1,746,038 | 335,239,296 | Filter Manager file-object contexts |
| FMwi | Nonpaged | 1,745,626 | 223,440,128 | Filter Manager work items |
| WCfc | Nonpaged | 1,023,494 | 212,886,752 | Confirmed present in wcifs.sys |
| WCse | Paged | 1,745,606 | 111,718,784 | Wcifs-related tag |
| WCss | Paged | 1,745,606 | 111,718,784 | Wcifs-related tag |

Several WC* tags had approximately zero frees. Inspection of the installed Microsoft driver confirmed that WCsc and WCfc are allocation tags embedded in:

C:\Windows\System32\drivers\wcifs.sys

File description: Windows Container Isolation FS Filter Driver.

At the same time:

• vmmemCmZygote was present.
• hcsdiag list -raw showed one Windows VM owned by CmService in SavedAsTemplate state.
• wcifs had three active filter instances.
• Docker was not running.

Reboot comparison

A reboot cleared nearly all of the abnormal state:

| Counter | Before reboot | Approximately 2 minutes after reboot |
|---|---:|---:|
| System handles | 1,756,881 | 12,242 |
| Paged pool | 7.82 GB | 1.25 GB |
| Nonpaged pool | 4.87 GB | 1.02 GB |
| Committed memory | 69 GB | 20.9 GB |
| FMfn | 2,472 MB | 196 MB |
| WCsc | 639 MB | 1.04 MB |
| WCri | 505 MB | 0.69 MB |
| WCfc | 203 MB | 0.41 MB |

vmmemCmZygote was absent immediately after reboot.

Controlled Codex sandbox test

After beginning sandboxed Codex work again, without launching Docker or Windows Sandbox manually:

• vmmemCmZygote reappeared.
• FMfn grew from approximately 196 MB to 273 MB.
• Outstanding FMfn allocations grew from 391,258 to 538,397.
• File-object pool usage grew from approximately 51 MB to 66 MB.
• Paged pool grew from approximately 1.25 GB to 1.58 GB.

The WC* tags increased only slightly during this short test and then remained stable over a 30-second sample. This suggests the severe condition may require prolonged use, repeated sandbox lifecycle operations, or particular repository/directory workloads.

I cannot yet prove that Codex directly owns the Wcifs allocations, but sandboxed Codex activity correlated with vmmemCmZygote activation and Filter Manager cache growth. The pre-reboot PoolMon state and complete reboot reset appear consistent with persistent kernel filesystem/container state rather than ordinary Codex process-private memory.

I have retained the sanitized PoolMon snapshots and can collect a longer WPR Pool/Handle trace or additional before/after samples if useful.

Additional clean-boot reproduction with PoolMon, FilterManager event correlation,
Git process-start sampling, and a prior crash dump.

Environment

• Windows 11 25H2, build 26200.8875, x64, 16 GB RAM
• Codex Windows Store package: OpenAI.CodexBeta_26.727.4816.0_x64
• bindflt.sys: 10.0.26100.8655, valid Microsoft signature
• ntfs.sys: 10.0.26100.8875, valid Microsoft signature
• WSL and Windows Containers disabled; no active WSL/Docker/HCS compute system
• Claude CoworkVMService disabled and stopped; vmcompute stopped
• Windows Widgets disabled by policy; WidgetBoard/WidgetService absent
• bindflt service startup was set to Disabled before this boot to make its

subsequent on-demand load visible. I did not unload the live filter.

Clean-boot control and exact activation timeline

Windows booted at 10:50:21.500 local time. A SYSTEM monitor sampled once per
minute.

Before Codex Desktop launch:

| Time | Nonpaged pool | bindflt | Codex private bytes |
|---|---:|---|---:|
| 10:51:39 | 131 MB | Stopped/Disabled | 0 MB |
| 10:56:55 | 141 MB | Stopped/Disabled | 0 MB |
| 11:02:01 | 165 MB | Stopped/Disabled | 0 MB |

At 11:02:33, two independently logged events have the same timestamp:

1. Microsoft-Windows-AppModel-Runtime created the process and Desktop AppX

container for OpenAI.CodexBeta_26.727.4816.0_x64.

1. Microsoft-Windows-FilterManager, System event ID 6: `File System Filter

'bindflt' ... has successfully loaded and registered with Filter Manager.`

After Codex Desktop launch:

| Time | Nonpaged pool | bindflt |
|---|---:|---|
| 11:03:33 | 210 MB | Running/Disabled |
| 11:08:54 | 576 MB | Running/Disabled |
| 11:19:31 | 1,020 MB | Running/Disabled |

Growth from 11:03:33 to 11:19:31 was 50.74 MB/min. Growth over the last
10 minutes of that interval was 41.83 MB/min.

PoolMon attribution

An official Microsoft PoolMon snapshot at 11:19:44 showed one dominant
nonpaged tag:

Tag   Type   Allocs      Frees       Outstanding   Bytes        Per alloc
NtFC  Nonp   17,314,013  13,334,371  3,979,642     764,291,408  192

This is NTFS File Context/FCB allocation, not Codex process-private memory.

On the preceding boot, the same NtFC tag grew from approximately 1.25 GB to
6.56 GB in the retained PoolMon snapshots, then total nonpaged pool reached
approximately 13.37 GB. System commit reached 94-96%, available RAM fell below
200 MB, and eventually even a local Get-Date command could not complete in
10 seconds. A normal Windows restart was the only recovery.

Git/root-detection amplifier

The Windows profile contained an empty repository root (<user-profile>/.git):
zero tracked files, zero objects, and no remotes. Therefore Codex treated the
entire user profile as the Git worktree even when the selected workspace was a
subdirectory.

During a 30-second Win32_ProcessStartTrace sample with Codex active:

git.exe       68 starts
conhost.exe   77 starts
taskkill.exe  34 starts

A repeat after restoring the original state measured 76 git.exe and 92
conhost.exe starts in 30 seconds. This is consistent with the profile-wide
Git-root amplifier described in an earlier comment on this issue. Disabling
the root live, without restarting Codex, caused even faster failed-probe
retries, so I restored the original Git state and did not present that as a
workaround.

Crash evidence

An earlier unexpected restart produced bugcheck 0x13A with bucket:

0x13a_17_bindflt!BfFormatPathFromFileNameInfo

The active process at the triggering file operation was git.exe. The dump is
retained locally. I will not attach raw dumps or the 4.46 GB WPR ETL publicly
because they can contain local paths and session data, but can provide them to
OpenAI/Microsoft engineers through a private channel.

Questions / suggested investigation

1. Is the on-demand bindflt load at Codex AppX activation expected?
2. Can Codex reject or require confirmation for a profile-wide Git root with no

tracked files, and rate-limit/back off repeated Git probes?

1. Which private upload channel should be used for the minidump, WPR Pool trace,

minute-by-minute CSV, FilterManager/AppModel events, and full PoolMon
snapshots?

All machine, organization, username, and internal-path identifiers have been
removed from this comment.

Independent reproduction on a high-spec Windows workstation, adding system-wide latency symptoms and reboot/app-restart boundaries.

Environment

• Codex Desktop package: OpenAI.Codex_26.803.10989.0_x64
• Windows 11 x64, OS build 26200
• The machine had substantial spare CPU and physical memory during several symptomatic samples.

User-visible impact

The slowdown affects the whole desktop, not just Codex:

• dragging windows/tabs shows visible trailing/ghosting and delayed composition
• YouTube playback and network-streamed media hitch
• games can suffer severe FPS drops and input latency
• ordinary CPU and RAM utilization do not explain the severity

A normal Windows restart restores responsiveness. Restarting only the Codex UI, or terminating accumulated old node/node_repl processes, did not reliably restore the same responsiveness.

Measured deltas

Across light/post-reboot and degraded states, observed values included:

• combined kernel-pool usage: approximately 1.23 GiB post-reboot versus approximately 6.2 GiB in a degraded state
• system-wide handles: approximately 124k versus 155k
• Codex-family working set: approximately 2.0 GiB versus 4.4 GiB

Separate long-uptime samples also showed large app-server child-runtime accumulation (up to 103 node and 104 node_repl processes). Cleaning those processes reduced one contributor but did not fully explain the persistent desktop/game latency, which is why the kernel-pool/handle component appears important.

The local logs_2.sqlite database was approximately 1.30 GiB and its WAL/state files were updated frequently. Defender activity and Codex/ChatGPT I/O were observed concurrently. That may amplify latency, but I do not yet have WPR/PoolMon attribution proving that the database path causes the kernel-pool growth.

Causality boundary

The strongest evidence is the lifecycle comparison:

1. responsiveness is restored by a full Windows reboot
2. the abnormal kernel/system state is reset by that reboot
3. the condition reappears during prolonged Codex Desktop use
4. app-only restart and child-process cleanup are incomplete mitigations

I am not claiming a specific pool tag or driver root cause without a PoolMon/WPR trace.

Requested investigation

• Add long-duration Windows regression tests covering paged/nonpaged pools, system handles, process count, and input/scheduler latency.
• Correlate Desktop/AppX sandbox, filesystem-filter, Defender, Git/WMI polling, SQLite logging, and MCP child-lifecycle events.
• Ensure a complete app restart releases all app-owned kernel objects and child runtimes.
• Provide a supported diagnostic bundle/private upload route for PoolMon/WPR/ETW data.

I can provide sanitized before/after tables privately; raw logs and local paths are intentionally omitted from this public comment.

The newer reports appear to confirm the original lifecycle finding across several later Codex builds: kernel-pool/system state grows during sustained Desktop use, the slowdown is system-wide rather than ordinary Codex private memory, stopping Codex limits further growth, and a Windows reboot is often required to recover the accumulated state.

Confirmed evidence: independent PoolMon captures show large filesystem-related allocations (NtFC, FM*, WC*); one clean-boot test correlated Codex AppX activation with bindflt loading and approximately 42–51 MB/min nonpaged-pool growth; another retained crash dump identifies bindflt!BfFormatPathFromFileNameInfo with git.exe active.

Likely amplifiers, not yet proven root causes: profile-wide Git roots and repeated Git/process creation; sandbox/container-filter lifecycle activity; accumulated child runtimes; and heavy SQLite/WAL plus security-filter I/O. GPU acceleration is a weaker explanation because the original report reproduced with GPU compositing disabled.

Could maintainers provide a private upload route and request one standardized bundle from affected users:

1. exact Codex package and Windows build;
2. clean-boot baseline plus timestamped Codex start/stop samples for commit, paged/nonpaged pool, handles, and process counts;
3. PoolMon snapshots before launch, during growth, after Codex exit, and after reboot;
4. WPR/ETW Pool + Handle + File I/O + Process traces covering the transition;
5. FilterManager/AppModel events, loaded filter list, and HCS/container state;
6. Git root selected by Codex and a short git.exe/conhost.exe/taskkill.exe process-start trace;
7. sanitized dump metadata—or the dump privately—if a bugcheck occurs.

That bundle should help distinguish the reproducible Codex lifecycle signal from machine-specific amplifiers without prematurely assigning one driver as the universal cause.

GPU acceleration is a weaker explanation because the original report reproduced with GPU compositing disabled.

Strange because for me I run Codex on two Windows 10 machines. At home where I have GPU acceleration and at work through remote desktop on a VM where there is no GPU. For me the problem only manifests on my home machine with GPU. At my work machine I do way more Codex work and go months without reboot and memory remains stable (no growth). At home I have to reboot every 5 days if I work with Codex as it eats up committed memory and doesn't release it. There may be other contributing factors between my physical and VM machine but not sure what.

I don't see how GPU could be relevant, given that it happens with headless CLI (for me at least). Do you have the sandbox installed on both systems?

No sandbox on either systems. Must be something else then. Can't figure out what.

________________________________
From: Erik Demaine @.*>
Sent: Friday, August 14, 2026 04:21 PM
To: openai/codex @.*>
Cc: Perry Manole @.>; Comment @.>
Subject: Re: [openai/codex] Windows desktop app triggers persistent kernel-pool growth and system-wide slowdown (Issue #29436)

[https://avatars.githubusercontent.com/u/2218736?s=20&v=4]edemaine left a comment (openai/codex#29436)<https://github.com/openai/codex/issues/29436#issuecomment-5299113960>

I don't see how GPU could be relevant, given that it happens with headless CLI (for me at least). Do you have the sandbox installed on both systems?

—
Reply to this email directly, view it on GitHub<https://github.com/openai/codex/issues/29436?email_source=notifications&email_token=AHISBZCFPYZROW7CDZOQYL35J6NHFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRZHEYTCMZZGYYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5299113960>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHISBZHSYWL7ISLPRJNY4Z35J6NHFAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TINZRGY2TONBSG42KC5QC>.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/AHISBZAIJH4ZJ2NYUVN2XST5J6NHFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRZHEYTCMZZGYYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android<https://github.com/notifications/mobile/android/AHISBZBOBDYF4YNM2QG3UMD5J6NHFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRZHEYTCMZZGYYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today!
You are receiving this because you commented.Message ID: @.***>