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

[xinaxinaxin]

Summary

The Codex Windows desktop app triggers sustained Windows kernel-pool growth on my machine. Memory usage rises toward 95% within about one hour, after which screenshots and clipboard operations become severely delayed. Closing ordinary applications does not recover the accumulated memory; restarting Windows clears it.

Controlled testing shows that the growth stops when all Codex desktop processes are closed. Disabling Chromium GPU acceleration does not resolve it.

Environment

• Codex package: OpenAI.Codex_26.616.6631.0_x64
• Codex Chromium: 149.0.7827.115
• Problem began after update from 26.611.8604.0 to the 26.616.x series on June 19, 2026
• Windows 11 Home China, 25H2, build 26200.8655
• Lenovo Legion R7000P APH8, model 82Y9
• 16 GB RAM
• AMD Radeon 780M, Lenovo OEM driver 31.0.14005.22001
• NVIDIA RTX 4060 Laptop GPU, Lenovo OEM driver 32.0.15.6624
• PowerShell/native Windows agent

Lenovo's driver utility reports the AMD, NVIDIA, and chipset drivers as the current OEM-recommended versions.

Reproduction

1. Restart Windows to clear the accumulated kernel memory.
2. Open the Codex Windows desktop app.
3. Use Codex normally for repository work for 30–60 minutes.
4. Observe Task Manager memory usage steadily rising.
5. Close other applications and then close Codex.
6. The system remains under high memory pressure; screenshot and clipboard operations remain slow until Windows is restarted.

No project development server, Python process, Playwright browser, WSL, or Docker VM was left running during the controlled comparisons.

Controlled measurements

Codex open, normal GPU mode — 5.08 minutes

• Available physical memory: -1019 MB
• Commit: +626.7 MB
• Nonpaged pool: +29.7 MB (+5.84 MB/min)
• Codex private bytes: -26.7 MB

The Codex user-mode private allocation did not explain the system growth.

Codex open, hardware acceleration disabled — 5.08 minutes

The Chromium process was verified to use --use-angle=d3d11-warp-webgl and renderer processes used --disable-gpu-compositing. Codex GPU process memory stayed at 0 MB.

• Available physical memory: -809 MB
• Commit: +681 MB
• Nonpaged pool: +45.7 MB (+8.99 MB/min)
• Paged pool: +24.7 MB
• Codex private bytes: +78.9 MB

Disabling hardware acceleration did not resolve the issue.

All Codex desktop processes closed — 5.08 minutes

Codex process count was continuously verified as zero.

• Commit: -41 MB
• Nonpaged pool: -7.3 MB (-1.44 MB/min)

The kernel-pool growth stopped when the Codex desktop app was fully closed. VS Code and the OpenAI Codex extension remained installed/running during this comparison.

Related issue

This may be related to #13749, but it is observably different: this report concerns sustained paged/nonpaged kernel-pool and system commit growth, it reproduces with Chromium GPU acceleration disabled and Codex GPU memory at 0 MB, and it stops only when all Codex desktop processes are closed.

Expected behavior

Kernel paged/nonpaged pools and system commit should stabilize during sustained Codex desktop use and should not require restarting Windows after roughly one hour.

Actual behavior

Kernel memory and commit grow while the desktop app is running. The growth stops when all Codex desktop processes are closed, but previously accumulated memory is not fully recovered without a Windows restart.

Current workaround

Use the Codex extension in VS Code and keep the Codex Windows desktop app closed.

I have retained the raw CSV samples from all four comparisons and can provide them if requested. I intentionally did not attach full Codex logs because they may contain session details.

[github-actions]

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

[Gruski]

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.

[Gruski]

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](https://github.com/openai/codex/issues/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.

[Hevinxue]

same problem

[Yassycodes]

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: #29949 (comment)

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.

[booobing]

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.