Memory leak

[uuuus]

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.616.71553 • Released 23 cze 2026

What subscription do you have?

plus

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Subject: Windows memory issue after Codex repo analysis - very high Page Table / system memory growth

I’m seeing a reproducible Windows memory issue related to Codex desktop after repository analysis.

Environment:

• Windows 11
• 32 GB RAM
• Codex desktop app
• F-Secure installed
• Local repo analyzed: Novera

Observed behavior:

1. After reboot, baseline memory usage is low/normal.
2. Launching Codex alone causes only a small increase.
3. Running a broad repository analysis in Codex increases memory usage significantly.
4. Excluding the repo folder from F-Secure reduced the worst spikes, so antivirus scanning was clearly part of the issue.
5. However, even after the prompt completes and no active prompt is running, memory continues creeping upward over time.
6. Codex-related helper processes remain alive in the background, but their private memory does not explain the full RAM usage.

Important findings from RAMMap:

• Total memory usage in Task Manager reached about 73%
• Process Private: ~4.0 GB
• Mapped File: ~11.8 GB
• Page Table: ~5.7 GB
• Paged Pool: ~2.46 GB
• Nonpaged Pool: ~1.44 GB

This seems important:

• Codex processes themselves are relatively modest in RAM usage
• The largest Codex processes were roughly:
  • ~240 MB
  • ~156 MB
  • ~90 MB
  • ~88 MB
• So the overall RAM problem does not appear to come from a simple Codex.exe user-space memory leak

Why I suspect a Codex-related issue:

• Codex is the trigger: the problem starts after broad repo analysis
• After prompt completion, Codex does not return quickly to true idle
• Memory continues to rise slowly in the background
• The most abnormal RAMMap metric is Page Table memory (~5.7 GB), which suggests a kernel/system-level side effect rather than a normal app-only leak

Other potentially interacting software:

• F-Secure Endpoint Protection
• Wargaming Game Center / wgc_renderer_h
• OneDrive
  But the issue is consistently triggered by Codex repo analysis.

Expected behavior:

• After repo analysis completes, Codex should settle to near-idle
• Helper/background processes should shut down or stabilize
• Memory usage should stop growing when no active prompt remains
• System/kernel memory (especially Page Table) should not continue growing abnormally

Actual behavior:

• Codex analysis triggers continuing background activity
• RAM usage keeps increasing after prompt completion
• RAMMap shows unusually high Page Table and kernel-related memory usage

I have Task Manager and RAMMap screenshots showing the progression if needed.

What steps can reproduce the bug?

Feedback ID: 019ef5e3-22e6-7fb0-9654-08900e798282

What is the expected behavior?

not grow memory consumption

Additional information

No response

[github-actions]

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

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

Powered by Codex Action

[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]

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.

[antonnevm-cloud]

I am seeing a closely related Windows kernel-memory issue and opened a separate report with ETW/WPR evidence: #30926.

Short version: Codex Desktop 26.623.11225.0 on Windows 11 build 28000 repeatedly starts git.exe from the GUI process. In a mostly-idle ETW trace, Codex.exe started git.exe 263 times in ~54.6 seconds, mainly:

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

The corresponding kernel stack for Toke allocations is:

NtCreateUserProcess
PspAllocateProcess
PspInitializeProcessSecurity
SeSubProcessToken
SepDuplicateToken
ObCreateObjectEx
ObpAllocateObject
ExAllocatePoolWithTag

Close/reopen check: with Codex closed for 15 minutes, Token objects stopped growing (1,289,018 -> 1,288,882). After reopening Codex, they grew again in 60 seconds (1,289,270 -> 1,289,550).

[vvoois]

I noticed the same, did some more research now.

To make a summarized theory:
Memory leaking also happens when opening Visual Studio with the Codex plugin disabled, you see similar behavior:
Paged and non-paged memory use is rising with 50 to 128MB and then only partially dropping after closing Visual Studio
The question is whether the bug resides in Visual Studio and Codex only makes the bug more prominent
Or whether Codex is co-offending here with own routines.

Here some more measurements while Codex agent was active:
I did some measurements with pool-mon.

Here is the 0-offset:

I started to test from 21:00 and stopped the test at 22:29 (i closed Visual Studio) and from that moment you can see the non-paged pool remain steady.

Nothing is being freed however afterwards:
During the Visual Studio Code and codex session, you can see the non-paged pool grow fast and out of proportions:
Time PageTableMB PagedPoolMB NonpagedPoolMB

---

2026-07-15 20:59:08 0 1225 922,5
2026-07-15 21:00:09 0 1215,4 922,1
2026-07-15 21:01:09 0 1215,3 922,2
2026-07-15 21:02:09 0 1215,3 922,4
2026-07-15 21:03:10 0 1215,5 922,2
2026-07-15 21:04:10 0 1221,8 929,2
2026-07-15 21:05:10 0 1347 1001,8
2026-07-15 21:06:10 0 1393,2 1042,1
2026-07-15 21:07:11 0 1434,9 1071,4
2026-07-15 21:08:11 0 1472,3 1094,1
2026-07-15 21:09:11 0 1511 1118,4
2026-07-15 21:10:12 0 1538,7 1138,2
2026-07-15 21:25:34 0 1904,6 1375,6
2026-07-15 21:26:34 0 1884,3 1392,8
2026-07-15 21:27:35 0 1879,2 1408,4
2026-07-15 21:28:35 0 1907 1417,6
2026-07-15 21:29:35 0 1922,9 1427,2
2026-07-15 21:30:36 0 1957,3 1434,4
2026-07-15 21:31:36 0 1968,4 1442,9
2026-07-15 21:32:36 0 1973,7 1454,2
2026-07-15 21:33:37 0 2009,4 1467
2026-07-15 21:34:37 0 2016,9 1474,2
2026-07-15 21:35:38 0 2039,9 1482,6
2026-07-15 21:36:38 0 2051,6 1492,1
2026-07-15 21:37:38 0 2053,2 1504,2
2026-07-15 21:38:39 0 2086,5 1510,9
2026-07-15 21:39:39 0 2104,9 1526,4
2026-07-15 21:40:40 0 2119 1536,9
2026-07-15 21:41:42 0 2130,4 1547,7
2026-07-15 21:42:42 0 2153 1552,6
2026-07-15 21:43:43 0 2154,6 1554,6
2026-07-15 21:44:43 0 2201,1 1571,1
2026-07-15 21:45:44 0 2181,3 1576,7
2026-07-15 21:46:44 0 2183,8 1581,8
2026-07-15 21:47:45 0 2196,4 1587,8
2026-07-15 21:48:45 0 2203,8 1596,3
2026-07-15 21:49:45 0 2212,2 1604,7
2026-07-15 21:50:46 0 2222,6 1611
2026-07-15 21:51:46 0 2231,9 1617,8
2026-07-15 21:52:47 0 2240,9 1624,1
2026-07-15 21:53:47 0 2251,2 1633,4
2026-07-15 21:54:47 0 2260,8 1639,3
2026-07-15 21:55:48 0 2271,2 1646,5
2026-07-15 21:56:48 0 2279,7 1652,4
2026-07-15 21:57:50 0 2288 1659,9
2026-07-15 21:58:51 0 2296,9 1665,5
2026-07-15 21:59:51 0 2305,4 1672,3
2026-07-15 22:00:51 0 2312,1 1676,3
2026-07-15 22:01:52 0 2320,2 1684,2
2026-07-15 22:02:52 0 2327,3 1687,9
2026-07-15 22:03:52 0 2334,2 1695,3
2026-07-15 22:04:53 0 2341,9 1699,4
2026-07-15 22:05:53 0 2349,5 1704,6
2026-07-15 22:06:54 0 2356,3 1710,6
2026-07-15 22:07:54 0 2364,7 1718,5
2026-07-15 22:08:54 0 2372,8 1722,2
2026-07-15 22:09:55 0 2379,7 1729,5
2026-07-15 22:10:55 0 2386,4 1732,9
2026-07-15 22:11:56 0 2392,2 1739
2026-07-15 22:12:56 0 2400,3 1746,2
2026-07-15 22:13:58 0 2407,7 1751,4
2026-07-15 22:14:58 0 2415,7 1756
2026-07-15 22:15:59 0 2423 1758,5
2026-07-15 22:16:59 0 2426,3 1766,9
2026-07-15 22:18:00 0 2432,5 1773,7
2026-07-15 22:19:00 0 2439,7 1779
2026-07-15 22:20:01 0 2446,4 1783,3
2026-07-15 22:21:01 0 2453,6 1787,1
2026-07-15 22:22:02 0 2461,7 1793,3
2026-07-15 22:23:02 0 2477,2 1799,8
2026-07-15 22:24:02 0 2472,4 1803
2026-07-15 22:25:03 0 2480,7 1809,1
2026-07-15 22:26:03 0 2487,7 1815,4
2026-07-15 22:27:04 0 2493,3 1821,9
2026-07-15 22:28:04 0 2501,4 1827,3
2026-07-15 22:29:04 0 2500,5 1830,1
2026-07-15 22:30:06 0 2493,9 1823,2
2026-07-15 22:31:06 0 2493,6 1823,1
2026-07-15 22:32:53 0 2502,3 1826,7
2026-07-15 22:33:53 0 2493,5 1825,5
2026-07-15 22:34:53 0 2493,8 1829,6
2026-07-15 22:35:54 0 2493,2 1824,2
2026-07-15 22:36:54 0 2492,5 1822,9
2026-07-15 22:37:54 0 2492,2 1822,2
2026-07-15 22:38:55 0 2492,6 1821
2026-07-15 22:39:55 0 2492,7 1820,5
2026-07-15 22:40:55 0 2492,3 1820,1
2026-07-15 22:41:56 0 2492,6 1820,9
2026-07-15 22:42:56 0 2492,4 1820,7
2026-07-15 22:43:56 0 2494,4 1821,8
2026-07-15 22:44:56 0 2494,1 1821,9

Reference point:

Here is my suspicion:

Codex is running a massive amount of secondary processes (Powershell, Cmake, etc).
The generic code in Codex does this very same behavior on every platform:
Start secondary process, then kill process (taskkill).

On Unix/Linux this apparently kills all attached subprocessed that are running inside these secondary processes, but on Windows / Mac this might not be the case which is where the leak may start to occur.

So i am not sure if this can be fixed and if, then how, because Powershell in some cases have to run as Admin but a lot of processes are mostly run in a sandbox.
If there would some kind of fix, this would require some kind of virtual machine environment inside Visual Studio that you can close and allow the system to fashionably restore the memory consumption.

But i actually consider this a bug in Windows / Mac rather than Codex.
the platform environment is not properly taking care of it's memory when processes are being killed or perhaps they do, but not at the speed that Codex is calling these processes and killing them (garbage collection is not working fast enough).

If there is a fix possible in Codex, this i suspect should then be that Codex should also fully release the secondary process after killing the task instead of just killing it and consider the OS is going to do the rest automatically.
The idea that the pool remains steady after the closure of Visual Studio gives the idea that Codex is also not doing something right on their part

But this counts solely for their VISX solution, not sure if the CLI solution is culprit

Edit:
Okay, letting ChatGPT solve one part of OpenAi's own issue, it detects an issue with this routine (windows-sandbox-rs/.../command_runner/win.rs):
let h_job = unsafe { create_job_kill_on_close().ok() };

if let Some(job) = h_job {
unsafe {
let _ = AssignProcessToJobObject(job, pi.hProcess);
}
}

And suggests to solve it rather this way instead of blindly kiling the job with all processinfo with it:
let job = unsafe { create_job_kill_on_close() }
.context("failed to create process-tree job")?;

unsafe {
assign_process_to_job(job.raw(), pi.hProcess)
.context("failed to assign child to process-tree job")?;
}

This stuff also does not look right (utils/pty/src/process.rs):
self.request_terminate();

if let Some(handle) = self.wait_handle.take() {
handle.abort();
}

First you terminate and then you are going to check handles?

The generic problem is that Codex allows context to exist for 30 minutes before it allows it to free.
This is understandable for your chatcontent and the results from external tools, external process handles should not be included here and it looks like these are being reserved for 30 minutes as well.

Well, at least OpenAI can use GPT 5.6 to solve this one.