Pricing

Gemini CLI "FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory"

Q: How do I fix Gemini CLI JavaScript heap out of memory?

Shrink context with `/compress` or `/clear`, restart long sessions, update the CLI for builds that include the #30180 mitigation once released, and treat a larger `--max-old-space-size` as a delay only (#29830, commands docs).

Q: What is the high memory warning before the crash?

#29591 quotes `⚠ High memory usage detected: 7.28 GB…` when RSS passes about 7 GB; treat it as a stop-and-trim signal.

Gemini CLI crashes with "FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory"? Causes from GitHub and the fixes that stick.

By Engineer Foodie Desk Nov 7, 2026 ✓ Sources checked Nov 7, 2026

6 min read

Crash string and issue trail checked Nov 7, 2026 on Gemini CLI’s GitHub (issue #29830, #29591, #26588 and PR #30180). CLI commands checked Nov 5, 2026 in the Gemini CLI command reference. Every source is listed at the bottom. No affiliate links on this page (how we work).

Lead finding: this crash is your local Node/V8 process hitting its heap ceiling, not Gemini rejecting you with a 429 or a 503. One long interactive session in #29830 ran about 9.3 hours and died around 8.29 GB of heap. A mitigation PR landed on main on Nov 6, 2026. Until a release note names the fixed CLI version, treat the crash as real, shrink the session, and don’t cargo-cult a bigger heap as the “fix”.

The exact error: `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory`

This is the FATAL line as it appears in the title of issue #29830 on Google’s gemini-cli repo (verified Nov 7, 2026):

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

The issue title also tags it as a crash with “V8 Heap Limit Exceeded at ~8.3GB”. Same FATAL string shows up after the high-memory warning in #29591 and in the older stack in #26588.

One-line answer: the Node process that runs Gemini CLI ran out of V8 heap. That is a local process crash. It is not an API 429 “resource exhausted” response and it is not a 503 “model overloaded” response.

If the wall of red text feels like Wall-E’s Axiom filling with trash until the ship can’t breathe, that’s the right mental model. The process kept holding multimodal junk and tool output until V8 said no.

What the issues report

Only what the cited issues show, with dates.

#29830 (opened Oct 19, 2026; closed completed Nov 6, 2026; Gemini CLI 0.64.0, Node v24.10.0, Windows 11). One interactive session ran ~9.3 hours. Heap sat around 8.29 GB when it died. The issue was cross-referenced to merged PR #30180 (fix(core): bound multi-part tool outputs and evict older multimodal inlineData, merged Nov 6, 2026 into main). The PR does not name a released CLI version. Fixed-in release version: not published as of Nov 7, 2026.

#29591 (opened Oct 1, 2026; still open as of Nov 7, 2026; CLI 0.62.0). Title warning, verbatim:

⚠  High memory usage detected: 7.28 GB. If you experience a crash, please file a bug report by running /bug

Then the same FATAL ERROR line. The bot note on that issue says the warning comes from a memory monitor when RSS exceeds 7 GB, and points at large PDFs kept as base64 inlineData in history. A user on that thread said converting PDF to markdown alleviated the problem. That is a user note, not an official doc.

#26588 (opened May 6, 2026; closed stale Sep 6, 2026; CLI 0.41.1). Same FATAL ERROR stack after listing around 1,000 files. A user claimed a streaming PR fixed it; the issue later auto-closed as stale. Do not treat that as a confirmed shipped fix without a release note.

Pattern across the three: long sessions, big multimodal context (PDFs as inlineData), or huge file lists. Not “your API key is bad.”

Fixes in order (only what sources support)

Update Gemini CLI when a build with the mitigation is available. PR #30180 merged to main on Nov 6, 2026 and #29830 was closed completed against that work. No “update to version X fixed it” confirmation is published on that issue, and no release number is named in the PR. So: update to the latest published release, and if your build still OOMs on a short session, file /bug with the CLI version and the FATAL line. Do not invent a version that “fixed” it.
Shrink the chat context with /compress or /clear. The Gemini CLI command reference (verified Nov 5, 2026) defines /compress as: “Replace the entire chat context with a summary. This saves on tokens used for future tasks while retaining a high level summary of what has happened.” /clear clears the conversation context and starts a new session. The heap issues are about retained history and multimodal blobs, so a smaller session is the honest first move. /compress is not listed as a heap-OOM workaround inside the #29830/#29591 bodies (only a generic wish to “compress the history” shows up as a recommendation wish on #29830). Use it because the commands docs say it shrinks context, not because Google stamped it on the crash ticket.
Restart the CLI / start a new session every few hours on long interactive days. The reporter’s temporary procedure on #29830 includes /clear or a new session every few hours, plus adding large directories to .geminiignore. Quote that as user-reported temporary procedure, not maintainer gospel.
NODE_OPTIONS=--max-old-space-size=… only as a delay, and only as documented on the issue. The same #29830 body lists a PowerShell temporary step: $env:NODE_OPTIONS = "--max-old-space-size=12288" then gemini. The same reporter later wrote: “A higher heap limit is not a correction… The CLI starts Node.js with a larger --max-old-space-size. A larger limit only makes the crash occur later.” No official Gemini CLI doc fetched for this batch publishes that flag as the supported fix. If you raise the heap, you are buying time, not fixing retention. Mark Watney in The Martian would call that “work the problem,” not “hope the tank never empties.”

Skip account farming, proxy relays, and quota-bypass scripts. They do nothing for a local V8 crash, and they aren’t legit fixes.

Heap OOM vs API errors

Symptom	What it is	Next stop
FATAL heap OOM	Local Node/V8 crash	This page
429 exhausted	Your meter / quota	Gemini CLI 429
503 overloaded	Model capacity	Gemini CLI 503
Free-tier caps	Daily / access limits	Gemini CLI free tier limits

A heap OOM kills the process on your machine. A 429 or 503 comes back as an API status. If you’re hunting alternatives after too many CLI landmines, Gemini CLI vs Claude Code and AI coding tools compared are the next stops.

Here’s what I’d do

If you see the high-memory warning first, stop and /compress or /clear before the FATAL line arrives. On a fresh crash after a long multimodal session, restart, drop the big PDFs or convert them outside the CLI, and keep .geminiignore honest about giant dirs. Update the CLI so you’re not stuck on a pre-#30180 build once a release ships that merge. Raise --max-old-space-size only if you accept the #29830 reporter’s own caveat that it delays the crash. Don’t buy a higher Gemini plan to fix a local heap limit. Nothing in these issues says paying changes V8’s ceiling.

FAQ

What does Gemini CLI FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory mean? It means the Node/V8 process that runs Gemini CLI hit its heap ceiling and crashed locally; see issue #29830 (verified Nov 7, 2026).

Does heap out of memory mean I hit my Gemini free tier? No. Free-tier and quota problems show up as API limit errors, not as a local FATAL heap crash; see Gemini CLI free tier limits.

How do I fix Gemini CLI JavaScript heap out of memory? Shrink context with /compress or /clear, restart long sessions, update the CLI for builds that include the #30180 mitigation once released, and treat a larger --max-old-space-size as a delay only (#29830, commands docs).

What is the high memory warning before the crash? #29591 quotes ⚠ High memory usage detected: 7.28 GB… when RSS passes about 7 GB; treat it as a stop-and-trim signal.

Was the crash fixed? #29830 was closed completed Nov 6, 2026 against PR #30180 on main; a named fixed release version is not published as of Nov 7, 2026.

Sources

gemini-cli issue #29830 (verbatim FATAL ERROR; ~9.3h session; ~8.29 GB heap; closed completed Nov 6, 2026; reporter temporary procedure and heap-limit caveat): https://github.com/google-gemini/gemini-cli/issues/29830 (verified 2026-11-07)
gemini-cli pull #30180 (fix(core): bound multi-part tool outputs and evict older multimodal inlineData, merged Nov 6, 2026 into main): https://github.com/google-gemini/gemini-cli/pull/30180 (verified 2026-11-07)
gemini-cli issue #29591 (high-memory warning at 7.28 GB, then same FATAL ERROR; large PDF inlineData; open as of Nov 7, 2026): https://github.com/google-gemini/gemini-cli/issues/29591 (verified 2026-11-07)
gemini-cli issue #26588 (same FATAL ERROR after listing ~1000 files; closed stale Sep 6, 2026): https://github.com/google-gemini/gemini-cli/issues/26588 (verified 2026-11-07)
Gemini CLI, Commands (/compress, /clear, /bug): https://geminicli.com/docs/reference/commands/ (verified 2026-11-05)

The exact error: FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory