Browser extension: memory leak in every tab renderer, grows until macOS kills the machine (66 GB)
Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 8, 2026
Environment
- Claude browser extension 1.0.85 (installed since April 2026, earlier versions affected too)
- Brave 1.93.129 (Chromium 151), macOS 26.5.2, MacBook Pro M3 Pro, 36 GB RAM
What happens
With the extension enabled, every tab renderer slowly grows until it hits the V8 heap limit (~4 GB). With ~30 tabs open, Brave reached 66 GB resident and macOS ran out of memory. This was happening daily for months (~150 crash dumps since May).
The growth is uniform across all tabs, so I suspect the content scripts injected into <all_urls> (accessibility-tree.js runs in all frames at document_start). My fastest leaking tabs were DOM-heavy apps: Gmail, YouTube, LinkedIn. Looks like something accumulates on page mutations.
Evidence
- macOS Jetsam report (8 Aug, 09:17): 36 Brave processes, 66.02 GB resident. 15 renderers between 3.4 and 4.1 GB each, all pinned near the V8 ceiling.
- With the extension enabled: 4 renderers each grew ~1 GB within 9 minutes (+4.4 GB total).
- Disabled the extension, changed nothing else: the same 9-minute window went from +4.4 GB to +0.36 GB. Worst renderer delta went from +1,015 MB to +2 MB.
- Right after disabling, the leaking renderers each released 450-500 MB (GC reclaiming the leaked objects).
- Rest of the day after disabling: stable at 14-15 GB for ~30 tabs, no renderer above 1.4 GB.
Repro
- Install the extension, open a few DOM-heavy tabs (Gmail, YouTube, LinkedIn)
- Leave them open and watch renderer memory in the browser task manager
- Each renderer climbs toward 3.5-4 GB over hours
- Disable the extension: growth stops and memory drops
Notes
- Related: #37544 reported constant CPU from the extension service worker. This one is renderer memory, so different symptom, maybe same area.
- I kept the Jetsam reports, ps samples and timestamps if you need them.