Codex 5.4 Extra High Memory Leak
What version of the IDE extension are you using?
Latest
What subscription do you have?
Pro
Which IDE are you using?
VS Code
What platform is your computer?
Darwin 25.2.0 arm64 arm
What issue are you seeing?
Unconfirmed.
I use Codex at a very high throughput on Extra High Thinking on the 5.4 Model. This is all I use the computer for.
I see the system data memory on my macOS has reached over 400 GB on my 500 GB machine.
The more I use Codex, the more it continues to creep up until it is full and my computer crashes.
I have searched through the .codex folder and it's taking up less than 2 GB of space.
I suspect that there is some place that IDE Codex might be leaking data that it uses into some system data subfolder, though I haven't actually confirmed this. Just wanted to put this out there in case anyone is facing a similar issue or has solved it before.
What steps can reproduce the bug?
I run multiple tasks at once for long periods of time on 5.4 Extra High thinking.
What is the expected behavior?
Memory that Codex utilizes to execute is cleaned up by Codex.
Additional information
_No response_
10 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Using 5.4 for an extended period causes my 32GB of ram to be fully used. Even when i do nothing it stays 98% until i close VsCode.
And the issue only became felt when i started using 5.4.
I am getting this same issue (Mac, latest OS), but I've been getting it for several versions now. I extensively use subagents, and I exclusively use GPT-5.4 xhigh in multiple tabs. When I check for processes using memory, I see tons of them using node and playwright.
When I clear them out, memory drops back to normal, but it creeps back up, so it seems like something is leaking these processes, and they're not getting cleaned up.
Same issue here on the desktop app. I have 64gb of ram and it takes no more than 2hrs running a task on 5.4 and extra high thinking before ran is at 100% and I have to restart the PC to clear it out
Same issue here. VSCode extension. Using model 5.4. I'm not even doing anything especially heavy with it. Small tasks at a time. I'm wondering if it might have to do with the length of a chat. I tend to stay in one chat for a really long time.
VSCode extension leaks memory even when idle (windows+wsl setup). That is a recent behavior, a couple of weeks ago I had no issues
hello this issue also started when the issue of high token consumption started, is this issue under review by someone? I could notice that recently even my codex panel got restarted when it grows too much on memory consumption, and obtained from the ps -A in my linux machine that the process consuming too much ram is my codex extension...
i'm suspicious of this too. has anyone found a way to clear up the space?
100% memory leak, i'm using my VPS on daily driver with hermes no problem at all, tried codex CLI and all my services went down due the amount of memory usage
I can confirm the issue here on Windows 11 25H2.
I did some measurements with pool-mon.
Here is the 0-offset:
<img width="1458" height="1782" alt="Image" src="https://github.com/user-attachments/assets/f1dce485-d9ef-483f-8f40-d569da058a69" />
<img width="1315" height="1811" alt="Image" src="https://github.com/user-attachments/assets/f1fdc69f-2692-43ad-a847-6894fc8d847c" />
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:
<img width="1341" height="1790" alt="Image" src="https://github.com/user-attachments/assets/121bd841-cee7-489e-bc2e-5af23366aff9" />
<img width="1323" height="1802" alt="Image" src="https://github.com/user-attachments/assets/0a9c4f9c-d2ba-4430-bb91-5caeaf73942e" />
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.