You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
The Codex CLI has a serious memory leak issue that causes computer crashes. #9345
Hmm, interesting. Twenty minutes is not very long. I was kind of expecting you to say "it's been running for 48 hours". :)
Do you remember when you last launched codex? Did you start it right before that session, or has it been working on other sessions prior to that?
This is a new Codex CLI task I started in a fresh terminal. After restarting my computer, I tried to recover the session, but it seems the history wasn't saved—likely because of the physical reboot (though that’s a separate issue).
It looks like you're using iTerm as a terminal emulator. I guess we need to determine whether the memory leak is in Codex or in iTerm.
What is your scrollback setting in iTerm? Is it unlimited? If so, that might explain the problem you're seeing.
I checked my iTerm profile settings — scrollback is limited to 1,000 lines
(Unlimited scrollback is disabled).
So it doesn’t look like an iTerm scrollback issue.
Given that, this seems more likely to be memory retained by Codex itself
(or a subprocess) during the large batch delete (~1800 files).
Im having the same issue with the Vs Code extension. Instantly goes to 90% cpu, memory, and disk usage before crashing my whole computer a few minutes later. Spins up a nodejs runtime that hits 14 GB memory within a few seconds.
Im in windows 11.
Started with a prompt to explain a small section of my code and why it might be behaving a certain way
Happens on extension version 0.4.58 and 0.4.60. No issues on 0.4.56
@anthony-b-dev, that isn't the same problem described by the OP of this issue. @minorcell is reporting a large memory usage with the CLI process running in iTerm. If you're seeing a large memory usage in a node process, that's something different. Please use the /feedback command to open a new bug report.
Yes, Codex deleted my entire F drive today, and it ran very slowly. I think there are serious problems with the development of the Codex product; both the CLI itself and the underlying concepts are extremely poor.
Yes, Codex deleted my entire F drive today, and it ran very slowly. I think there are serious problems with the development of the Codex product; both the CLI itself and the underlying concepts are extremely poor.
@minorcell, you mentioned that your session involved many (1800) file deletions. Were these particularly large files (hundreds of MB)? If so, I think I have a working theory. If not, then I'm still grasping for more clues about what is special about your scenario. Have you seen this happen again, or was it just that one time?
@atimmer, do you recall if your session involved any large file deletions? If not, are there any other details about your session that might be atypical? Are you also on macOS?
No, I also can also no longer reproduce it. The RAM usage right now is unremarkable.
I did have heavy codex sessions on Friday and my battery was drained this morning. So perhaps it was a slow issue that occurred in the background.
The other process with tons of RAM usage was Cursor. With 50GB. iTerm was on 200GB. I have installed iStatMenus with a notification on high RAM pressure, so maybe I catch it next time. If so, are there any diagnostics I can run to help debug the issue?
do you recall if your session involved any large file deletions?
Definitely not today. On Friday, I don't know. Yes, I'm on macOS.
@atimmer if you see this again, please use the /feedback slash command to upload your logs and session details, then post the thread ID here. @minorcell wasn't able to capture his logs or session details because his machine crashed before the logs were flushed to disk.
@minorcell, you mentioned that your session involved many (1800) file deletions. Were these particularly large files (hundreds of MB)? If so, I think I have a working theory. If not, then I'm still grasping for more clues about what is special about your scenario. Have you seen this happen again, or was it just that one time?
@etraut-openai modified a total of 1884 files, with a total size of 45,405,611 bytes (approximately 43.30 MiB).
@tommy-tai , this issue has been addressed. If you are seeing a similar symptom, please open a new issue and provide details including repro steps if possible.
Activity
[-]Severe memory leak[/-][+]The Codex CLI has a serious memory leak issue that causes computer crashes.[/+]etraut-openai commentedon Jan 16, 2026
Thanks for reporting.
We haven't had other reports of such massive memory usage, but a memory leak is quite possible given the symptom you're seeing.
Was this a really long session? Refactors often involve really long sessions.
minorcell commentedon Jan 16, 2026
About twenty minutes into the task, I had the Codex CLI delete a large number of related files, approximately 1800.
etraut-openai commentedon Jan 16, 2026
Hmm, interesting. Twenty minutes is not very long. I was kind of expecting you to say "it's been running for 48 hours". :)
Do you remember when you last launched codex? Did you start it right before that session, or has it been working on other sessions prior to that?
minorcell commentedon Jan 16, 2026
This is a new Codex CLI task I started in a fresh terminal. After restarting my computer, I tried to recover the session, but it seems the history wasn't saved—likely because of the physical reboot (though that’s a separate issue).
etraut-openai commentedon Jan 16, 2026
It looks like you're using iTerm as a terminal emulator. I guess we need to determine whether the memory leak is in Codex or in iTerm.
What is your scrollback setting in iTerm? Is it unlimited? If so, that might explain the problem you're seeing.
minorcell commentedon Jan 16, 2026
I checked my iTerm profile settings — scrollback is limited to 1,000 lines
(Unlimited scrollback is disabled).
So it doesn’t look like an iTerm scrollback issue.
Given that, this seems more likely to be memory retained by Codex itself
(or a subprocess) during the large batch delete (~1800 files).
minorcell commentedon Jan 16, 2026
@etraut-openai
This doesn’t happen very frequently, so it’s been hard to get a reliable repro so far.
I’ll keep an eye on this going forward, and if it happens again, I’ll do my best to preserve detailed logs and report back.
For reference, the operation that deleted ~1800 files corresponds to this commit:
https://github.com/minorcell/Cap/commit/62858bb842d98a56a9c51486af90271f2e8be21d
anthony-b-dev commentedon Jan 17, 2026
Im having the same issue with the Vs Code extension. Instantly goes to 90% cpu, memory, and disk usage before crashing my whole computer a few minutes later. Spins up a nodejs runtime that hits 14 GB memory within a few seconds.
Im in windows 11.
Started with a prompt to explain a small section of my code and why it might be behaving a certain way
Happens on extension version 0.4.58 and 0.4.60. No issues on 0.4.56
etraut-openai commentedon Jan 17, 2026
@anthony-b-dev, that isn't the same problem described by the OP of this issue. @minorcell is reporting a large memory usage with the CLI process running in iTerm. If you're seeing a large memory usage in a node process, that's something different. Please use the
/feedbackcommand to open a new bug report.AyinMostima commentedon Jan 18, 2026
Yes, Codex deleted my entire F drive today, and it ran very slowly. I think there are serious problems with the development of the Codex product; both the CLI itself and the underlying concepts are extremely poor.
minorcell commentedon Jan 18, 2026
Looks like this belongs to another thread?
atimmer commentedon Jan 19, 2026
I’m having the same issue with iTerm and codex CLI
minorcell commentedon Jan 19, 2026
Have similar issues occurred on other devices?
etraut-openai commentedon Jan 19, 2026
@minorcell, you mentioned that your session involved many (1800) file deletions. Were these particularly large files (hundreds of MB)? If so, I think I have a working theory. If not, then I'm still grasping for more clues about what is special about your scenario. Have you seen this happen again, or was it just that one time?
@atimmer, do you recall if your session involved any large file deletions? If not, are there any other details about your session that might be atypical? Are you also on macOS?
atimmer commentedon Jan 19, 2026
No, I also can also no longer reproduce it. The RAM usage right now is unremarkable.
I did have heavy codex sessions on Friday and my battery was drained this morning. So perhaps it was a slow issue that occurred in the background.
The other process with tons of RAM usage was Cursor. With 50GB. iTerm was on 200GB. I have installed iStatMenus with a notification on high RAM pressure, so maybe I catch it next time. If so, are there any diagnostics I can run to help debug the issue?
Definitely not today. On Friday, I don't know. Yes, I'm on macOS.
etraut-openai commentedon Jan 19, 2026
@atimmer if you see this again, please use the
/feedbackslash command to upload your logs and session details, then post the thread ID here. @minorcell wasn't able to capture his logs or session details because his machine crashed before the logs were flushed to disk.minorcell commentedon Jan 20, 2026
@etraut-openai modified a total of 1884 files, with a total size of 45,405,611 bytes (approximately 43.30 MiB).
jif-oai commentedon Jan 20, 2026
Do you have any
/experimentalfeatures enable? Any MCPs connected?joshka-oai commentedon Jan 20, 2026
Grab the version of your terminal (iTerm) for posterity (guessing probably 3.6.6, but could be 3.6.7 beta)
etraut-openai commentedon Jan 20, 2026
This should be fixed in the next release (this PR).
minorcell commentedon Jan 21, 2026
3.5.14
minorcell commentedon Jan 21, 2026
shadcn and supabase mcp.
tommy-tai commentedon Feb 1, 2026
been running into a similar experience:
etraut-openai commentedon Feb 1, 2026
@tommy-tai , this issue has been addressed. If you are seeing a similar symptom, please open a new issue and provide details including repro steps if possible.