OOM when running Claude in specific codebase

Status Fixed / completed
Maintainer reply ✓ Yes — igorkofman
Activity 5 comments · opened Mar 5, 2025 · closed Mar 18, 2025
💡 Likely answer: A maintainer (igorkofman, collaborator) responded on this thread — see the highlighted reply below.

This is all I've got.
It's the largest repo I work in, but I wouldn't call it huge, but only this one repo fails.

CC loads and MAYBE I can get to type something and press enter by the time it crashes.
Once out of 50 times I was able to run /doctor and it said no issue.

Some kind of instant memory leak

Every other repo worked fine and this one was one of the best that it understood until now, all the sudden, it is insta-crash.

It did happen to arise as I was cleaning out my folder of old, large log files though so I don't know, maybe it got stuck trying to load the biggest files I have or something

<--- Last few GCs --->

[1065410:0x23277000] 14924 ms: Scavenge (reduce) (interleaved) 4085.8 (4095.3) -> 4085.9 (4088.6) MB, pooled: 0 MB, 1.43 / 0.00 ms (average mu = 0.988, current mu = 0.971) allocation failure;
[1065410:0x23277000] 14940 ms: Mark-Compact (reduce) 4095.1 (4097.8) -> 4094.7 (4097.3) MB, pooled: 0 MB, 4.91 / 0.00 ms (+ 0.1 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 32 ms) (average mu = 0.981, curr

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

1: 0xebe335 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
2: 0x1329690 v8::Utils::ReportOOMFailure(v8::internal::Isolate, char const, v8::OOMDetails const&) [node]
3: 0x1329a2c v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate, char const, v8::OOMDetails const&) [node]
4: 0x158c965 [node]
5: 0x159fd72 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
6: 0x14e6f68 v8::internal::StackGuard::HandleInterrupts(v8::internal::StackGuard::InterruptLevel) [node]
7: 0x19d163e v8::internal::Runtime_StackGuardWithGap(int, unsigned long, v8::internal::Isolate) [node]
8: 0x7b51928af276
Aborted (core dumped)

View original on GitHub ↗

5 Comments

BranchManager69 · 1 year ago

This has now spread to a second repo.

It was making the biggest consecutive update that I've ever seen -- starting from clean state, I watched as it grew to use ~90% of the context -- which was great, until Cursor got an OOM and crashed. Upon reload, cannot do anything in CC in that repo anymore.

The weird part to me is that I am doing all of this on a remote server, so I don't know how a Cursor client OOM would even relate to my server's memory. Could be a red herring

igorkofman collaborator · 1 year ago

Sorry I'm unclear - are you reporting a Cursor issue or an issue with the Claude Code CLI tool?

bcherny collaborator · 1 year ago

This should be fixed with the latest. Feel free to re-open if you're still seeing this after updating!

mwmdev · 1 year ago

I get the same issue in some repos. System logs point to OOM issue.

``docker.service: Main process exited, code=killed, status=9/KILL``

Using 1.0.51

github-actions[bot] · 1 year ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.