Antigravity IDE (macOS) quits without warning: main/browser process hits V8 heap OOM after ~1–2 days uptime

Google Antigravity
,
1

Originally filed as GitHub issue [Bug]: Antigravity IDE (macOS) quits without warning: main/browser process hits V8 heap OOM after ~1–2 days uptime · Issue #1232 · google-antigravity/antigravity-cli · GitHub. The maintainers said that repo is for the Antigravity CLI only and asked me to post here.

Version
N/A (desktop app) — Antigravity IDE 2.5.5 (VS Code 1.107.0 base, commit ecfbad74d93962fc8ca485d93ab9b4f3d4cb6cf8, build 2026-08-13), Electron 39.2.3

Environment

  • OS: macOS 26.5.2 (25F84)
  • Shell: zsh
  • Terminal Emulator: N/A (desktop IDE, not the CLI)
  • Runtime Version: Electron 39.2.3 (bundled)
  • Hardware Details: Apple M1 Pro, 32 GB RAM. System memory was not under pressure (≈62% free while the app process itself was at ~2.7 GB).

Steps to reproduce

  1. Launch Antigravity IDE and open ~6 workspace windows (normal daily setup: agent panel, integrated terminals, git repos with many changed files, extensions listed below).
  2. Keep working normally and leave the app running (no restart).
  3. After roughly 29–48 hours the whole app disappears at once: every window closes, no “window crashed” dialog, no shutdown sequence in main.log.

Expected behavior
Memory of the main (browser) process stays roughly flat over a long session, and the app does not terminate.

Actual behavior
The main/browser process grows its JS heap until V8 aborts with an out-of-memory error, which kills the entire app.

Crashes in the last week (macOS runningboardd: termination reported by launchd (2, 5, 5), i.e. SIGTRAP; a Crashpad minidump is written each time):

Crash time (UTC+7) Session start Uptime before crash Minidump annotation electron.v8-oom.location
2026-10-10 16:27 2026-10-08 16:18 ~48 h Ineffective mark-compacts near heap limit
2026-10-12 15:45 2026-10-10 16:34 ~47 h Ineffective mark-compacts near heap limit
2026-10-13 22:38 2026-10-12 17:19 ~29 h MarkCompactCollector: young object promotion failed

Two earlier minidumps with the same signature exist from 2026-09-05 and 2026-09-11.

All of these minidumps carry ptype=browser, prod=Electron, ver=39.2.3, electron.v8-oom.is_heap_oom, so this is the Electron main process, not a renderer, the extension host or the language server. Clean quits on the same machine report (0, 0, 0), so these are not user/update restarts.

Memory growth of the current session (fresh launch 2026-10-13 22:38): after 12.7 h of uptime the main process Electron shows phys_footprint: 2749 MB (peak 2782 MB) in footprint -p <pid>. A healthy VS Code main process normally stays in the low hundreds of MB. In one 90-second sample its RSS grew ~20 MB.

Before each crash main.log shows repeated [warning] [perf] profiling STARTED … / profiling DONE … entries (several per hour), and then just stops. There is no lifecycle/quit logging.

Logs
Last lines of main.log before the 2026-10-12 15:45 crash (nothing after these):

2026-10-12 15:08:48.218 [info] Extension host with pid 48297 exited with code: 0, signal: unknown.
2026-10-12 15:09:03.271 [info] Extension host with pid 70149 exited with code: 0, signal: unknown.
2026-10-12 15:34:43.611 [info] update#setState checking for updates
2026-10-12 15:34:44.168 [info] update#setState idle

Last lines before the 2026-10-10 16:27 crash:

2026-10-10 16:20:39.783 [warning] [perf] profiling STARTED 71bcc23d-8e8c-4e9a-bd80-17d7fe6f5b07
2026-10-10 16:20:44.828 [warning] [perf] profiling DONE 71bcc23d-8e8c-4e9a-bd80-17d7fe6f5b07
2026-10-10 16:21:03.824 [warning] [perf] profiling STARTED 71bcc23d-8e8c-4e9a-bd80-17d7fe6f5b07
2026-10-10 16:21:46.783 [warning] [perf] profiling DONE 71bcc23d-8e8c-4e9a-bd80-17d7fe6f5b07

macOS unified log at the 2026-10-13 crash:

2026-10-13 22:38:45.548 powerd: Process Electron.673 ClientDied NoIdleSleepAssertion "Electron" age:29:19:08
2026-10-13 22:38:45.578 runningboardd: [app<application.com.google.antigravity-ide…>:673] termination reported by launchd (2, 5, 5)

Notes:

  • argv.json has "enable-crash-reporter": true, but the minidumps are still sitting in ~/Library/Application Support/Antigravity IDE/Crashpad/pending/ and were never uploaded. I’m not attaching them publicly because they contain environment variables and local paths. I can share them privately with the team.
  • No macOS .ips crash report is generated for these, because the process aborts itself through V8’s OOM handler.
  • Installed extensions: anthropic.claude-code, openai.chatgpt, nskha.perplexity-vscode (MCP), pawelhuryn.grok-vscode-phuryn, ms-python.python / debugpy / vscode-python-envs, ms-toolsai.jupyter (+ renderers/keymap/cell-tags/slideshow), meta.pyrefly, devsense.phptools-vscode (+ intelli-php, composer, profiler), shopify.ruby-lsp, llvm-vs-code-extensions.vscode-clangd, ms-vscode.live-server, mechatroner.rainbow-csv, muhammad-ahmad.xlsx-viewer, tomoki1207.pdf. Extensions run in the extension host, but the heap that runs out belongs to the main process.
  • Workaround: quit and relaunch the app (Cmd+Q) at least once a day.
  • I can attach the main process with --inspect and collect a sampling heap profile plus two heap snapshots a few hours apart, if that would help the team find what is retained.
2

Likely the same root cause as [2.5.5 / macOS] Main process crashes with V8 heap OOM after repeated file-watcher event storms (node_modules). In that thread @robtihanyi took a heap snapshot of the main process and traced the growth to integrated-terminal output that is buffered in the main process and never released (microsoft/vscode#234393, fixed upstream by PR microsoft/vscode#323980 in VS Code 1.138; Antigravity 2.5.5 is based on 1.107).

My setup matches: same build (2.5.5, Electron 39.2.3), several windows with integrated terminals open all day, and the same minidump signature (ptype=browser, Ineffective mark-compacts near heap limit). Adding this as a second report so the two can be linked. Picking up that upstream fix in the next release should cover both.

3

Hi @Minzihair_HCM,

Could you please share reproduction steps or screen recording to reproduce this issue?

4

Hi @Ambati_Rajendra, thanks for picking this up.

The reproduction steps are in the first post (Steps to reproduce 1–3). In short: run Antigravity IDE 2.5.5 with several windows that have integrated terminals open, keep it running for 1–2 days without quitting, and the main process eventually hits the V8 heap limit and the app closes.

A screen recording won’t show anything useful here. Nothing happens on screen before the crash: no error, dialog or freeze. After 29–48 hours every window just disappears at once. Recording for two days to catch that one frame would not tell you more than the logs and minidumps already do.

What I can give you that shows the actual cause:

  1. Crashpad minidumps. There are 4 of them (2026-09-11, 10-10, 10-12, 10-13), all with ptype=browser and electron.v8-oom.is_heap_oom. They contain local paths and environment variables, so please share a private upload link or email and I’ll send them.
  2. Heap evidence from the main process. I can relaunch with --inspect and take two heap snapshots a few hours apart, plus a sampling heap profile. That will show which objects are being retained.

This also looks like the same issue as [2.5.5 / macOS] Main process crashes with V8 heap OOM after repeated file-watcher event storms (node_modules). In that thread the main-process growth was traced to integrated-terminal output that is buffered and never released (microsoft/vscode#234393, fixed upstream in microsoft/vscode#323980, VS Code 1.138). Antigravity 2.5.5 is based on 1.107. Could you confirm whether the next release picks up that fix?

For now I quit and relaunch the app at least once a day. Since I started doing that on 2026-10-14, I have had no crashes.

A bit more context on impact: before I started the daily restart, it happened 2–3 times in a row, always without warning and always in the middle of running work. I run oh-my-pi (omp) agents in the IDE’s integrated terminal, so each crash killed the running sessions and I had to resume them from where they stopped.

I’m not the only one. A friend of mine who uses the Claude Code extension in Antigravity had the same sudden crashes and has moved back to VS Code. For now I’ve also moved my daily work to another tool (Orca). I really like Antigravity IDE’s workspace layout, though, and would love to come back, so I hope the root cause can be found soon. I’m happy to collect whatever data helps.

5

One more data point. I asked the oh-my-pi (omp) maintainers whether their terminal UI could be involved, since I mostly run omp in Antigravity’s integrated terminal: auth-gateway serve: unbounded heap growth (~7 GB after 3 days) as long-lived daemon · Issue #15841 · can1357/oh-my-pi · GitHub

Their answer, in short:

  • omp’s interactive TUI writes terminal bytes continuously while a model is streaming. If the IDE main process keeps every PTY output chunk, a chatty terminal app like this makes the leak grow faster. It is an accelerator, not the cause.
  • omp already throttles repaints (~30 fps max, backs off under output backpressure, skips unchanged rows). There is no user setting to reduce the output further, and lowering the IDE’s terminal scrollback doesn’t help, because the retained buffer sits upstream of the display.
  • The retainer they point to is the same one fixed in VS Code: microsoft/vscode#323980 (an unconsumed onProcessData buffer in the main process, fixed in 1.138). Antigravity 2.5.5 is based on 1.107, so it would need that fix backported.

This probably explains why it hits people running coding agents in the integrated terminal hardest. That includes me with omp and my friend with the Claude Code extension: these tools stream output for hours at a time.

Two questions for the team:

  1. Is a backport of vscode#323980 planned for an upcoming Antigravity release?
  2. Do you still want the minidumps and a main-process heap snapshot to confirm the retainer chain? If so, please send me a private upload link and I’ll collect them.