The Codex CLI has a serious memory leak issue that causes computer crashes.

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.

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.

About twenty minutes into the task, I had the Codex CLI delete a large number of related files, approximately 1800.

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?

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.

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).

@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

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.

Looks like this belongs to another thread?

I’m having the same issue with iTerm and codex CLI

I'm having the same issue with iTerm and codex CLI

Have similar issues occurred on other devices?

@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?

Have similar issues occurred on other devices?

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).

Do you have any /experimental features enable? Any MCPs connected?

Grab the version of your terminal (iTerm) for posterity (guessing probably 3.6.6, but could be 3.6.7 beta)

This should be fixed in the next release (this PR).

Grab the version of your terminal (iTerm) for posterity (guessing probably 3.6.6, but could be 3.6.7 beta)

3.5.14

Do you have any /experimental features enable? Any MCPs connected?

shadcn and supabase mcp.

been running into a similar experience:

$ codex --version
codex-cli 0.93.0

@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.