Claude for Chrome extension: renderer OOM crash (Aw, Snap!) on high-mutation React SPAs — geometric memory growth outside page heap

Memory-leak report: Claude for Chrome extension — renderer OOM crash ("Aw, Snap!") on high-mutation web apps

Reporter: Peter Sarantidis (peter.sarantidis@gmail.com)
Date: 2026-07-23
Environment: macOS (Darwin 25.5.0, Apple Silicon, 24GB RAM), Google Chrome 150.0.7871.130 → .186 (reproduced on both), Claude for Chrome extension (claude-in-chrome), production web app at autotech-intelligence.com / .app (React SPA).

Summary

With the Claude for Chrome extension enabled, tabs of a React single-page app reproducibly
crash with "Aw, Snap!" roughly 10–16 minutes after load while the tab is visible. Renderer
process memory doubles geometrically (≈×1.5 every 40s after an ignition point) from ~300MB to
4.5–5.5GB, then the renderer dies. Disabling the extension eliminates the crash entirely;
no other change does.

Evidence

1. Six Crashpad minidumps in one day, all with exception code EXC_BREAKPOINT (0x6) at the

identical instruction (Chrome Framework +0x769cd0c, a brk #0 following a fatal-report
call — V8/Chrome deliberate fatal, OOM-trap family). One deterministic failure, not corruption.

1. Process-level memory curve (ps RSS, 20s sampling): flat ~300MB for ~8 minutes → geometric

climb 341 → 542 → 802 → 1,262 → 2,260 → 3,266 → 4,529MB in ~3.5 minutes → renderer dead.
Reproduced at 5.5GB on a second run.

1. The page's own JS heap stayed at 14–29MB throughout (performance.memory sampled every 2s

until seconds before death), DOM node count frozen, zero iframes, no long tasks recorded —
the growth is outside the page's main world: an extension isolate and/or external
(ArrayBuffer-family) allocations. --js-flags=--max-old-space-size=512 did not cap the
growth in the 5.5GB run (external memory), though some later lives died near ~530MB
(mixed tipping points of the same accumulation).

1. Kill-test: kill -9 of the bloated renderer instantly produced the tab's "Aw, Snap!" —

confirming the ballooning process was the visible tab's renderer.

1. Controlled trials (one variable at a time):

• 1Password extension disabled → crash still reproduces (exonerated).
• Incognito window (no extensions), same app's logged-out page → flat 178MB for 20+ minutes.
• Google Docs Offline enabled in both dying and surviving conditions (parity-exonerated).
• **Claude extension disabled, same profile/window/session, user actively driving the app on

two domains → 22 minutes, every renderer flat, global peak 393MB, zero crashes.**

1. History: user reports "Aw, Snap at any time on any page" of this app for an extended period;

crash dumps exist from before any debugging session (e.g. Jul 22 04:33, Jul 23 15:59).

Suspected mechanism

The app's shell produces a continuous DOM-mutation stream (watchdog/sentinel ticks every 2–5s,
frequent React re-renders, credential-type input fields present). The extension's content-script
layer appears to accumulate per-mutation state (snapshots/observations/buffers) without release
on such pages. Consistent with: app-specificity (static sites unaffected), visibility dependence
(hidden tabs throttle timers/rendering ⇒ tabs survive hours in background but die in ~10 visible
minutes), and the geometric growth shape.

Repro sketch

1. Install the Claude for Chrome extension; open a React SPA with frequent DOM mutations and a

few-second timer cadence (any autotech-intelligence.com authed page reproduces for us).

1. Leave the tab visible and idle ~10–16 minutes.
2. Watch the renderer in Chrome Task Manager / ps: geometric memory growth → "Aw, Snap!".
3. Disable the extension, reload, repeat: flat memory, no crash.

Happy to provide the six .dmp files, the sampled memory curves, and timestamps on request.