Repository navigation
Memory leak: Bun/WebKit Malloc unbounded growth reaching 14GB+ within minutes #33453
Closed as duplicate
Description
Bug Description
Claude Code's main process exhibits a severe memory leak, with RSS growing from ~1.7GB to 14GB+ within a short session (~3 hours, minimal context). The leak is in the Bun runtime's WebKit Malloc allocator, not in user-space JavaScript allocations.
Environment
- Claude Code version: 2.1.72
- OS: macOS 26.3.1 (Build 25D2128)
- Hardware: MacBook Pro M1 Max, 64GB RAM
- Runtime: Bun (JavaScriptCore / WebKit)
Steps to Reproduce
- Start
claudeCLI - Have several MCP servers configured (playwright, chrome-devtools, serena, magic, morph-fast-apply, pencil, filesystem — 7-8 total)
- Use normally — the memory grows rapidly even with minimal conversation context
Observed Behavior
Memory growth timeline (sampled every 10 seconds during a single conversation turn):
10:04:59 8,761 MB
10:05:09 9,232 MB (+471 MB in 10s)
10:05:19 9,755 MB (+523 MB in 10s)
10:05:29 9,842 MB (+87 MB)
10:05:39 9,873 MB (+31 MB, stabilizing)
10:05:49 9,867 MB (-6 MB, minor GC)
~1GB growth in 30 seconds during a single tool-call interaction.
Memory Analysis (vmmap)
Physical footprint: 13.9G
Physical footprint (peak): 13.9G
Writable regions: resident=9.6G swapped_out=4.4G (total dirty ~14GB)
Key findings from vmmap:
| Region | Resident | Dirty | Notes |
|---|---|---|---|
| WebKit Malloc | 276MB | 210MB | Bun's JS heap allocator — dozens of 32MB blocks, mostly dirty |
| Writable regions (total) | 9.6GB | +4.4GB swapped | Main leak area |
| __LINKEDIT | 411MB | 0 | Normal (dylib symbol tables) |
| __TEXT | 211MB | 0 | Normal (code segment) |
| __BUN | 96MB | 0 | Bun runtime binary |
| DefaultMallocZone | 10.6MB | 10.6MB | Normal system malloc — NOT leaking |
WebKit Malloc region detail (partial):
WebKit Malloc 11cbc8000-11ebc8000 [ 32.0M 27.8M 26.6M 0K] rw-/rwx SM=COW
WebKit Malloc 11ebc8000-120bc8000 [ 32.0M 20.2M 18.8M 0K] rw-/rwx SM=COW
WebKit Malloc 149e98000-14be98000 [ 32.0M 30.3M 27.1M 0K] rw-/rwx SM=COW
WebKit Malloc 14be98000-14de98000 [ 32.0M 31.8M 25.0M 0K] rw-/rwx SM=COW
WebKit Malloc 14de98000-14fe98000 [ 32.0M 26.8M 15.0M 0K] rw-/rwx SM=COW
WebKit Malloc 14fe98000-151e98000 [ 32.0M 27.2M 15.7M 16K] rw-/rwx SM=COW
WebKit Malloc 151e98000-153e98000 [ 32.0M 22.3M 18.3M 16K] rw-/rwx SM=COW
WebKit Malloc 153e98000-155e98000 [ 32.0M 27.9M 13.2M 0K] rw-/rwx SM=COW
... (many more 32MB blocks)
Multiple 32MB WebKit Malloc regions are allocated and remain dirty (not freed), indicating JavaScriptCore's GC is not reclaiming memory properly.
Analysis
- The leak is NOT in MCP child processes — all child processes (serena, playwright, chrome-devtools, etc.) have stable memory (~80-185MB each, not growing)
- The leak is NOT in system malloc —
DefaultMallocZoneis only 10.6MB - The leak IS in Bun's WebKit Malloc — JavaScriptCore allocates 32MB chunks that accumulate and are never returned to the OS
- Memory grows with each tool call / conversation turn, suggesting objects created during request processing are not being GC'd
Expected Behavior
Memory should stabilize after GC, not grow unboundedly. A minimal conversation session should not consume 14GB+.
Workaround
Restart Claude Code (/exit then relaunch). Memory returns to normal (~200-400MB) after restart.
Reacted by Mriyam Tamuli
Activity
github-actions commentedon Mar 12, 2026
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
github-actions commentedon Mar 15, 2026
This issue has been automatically closed as a duplicate of #33413.
If this is incorrect, please re-open this issue or create a new one.
🤖 Generated with Claude Code
jnorthrup commentedon Mar 20, 2026
Related: Bun ASAN Investigation Found JSC GC Leaks
We identified 4 unique memory leaks through systematic ASAN/LSAN testing in Bun runtime. All trace to WebKit JavaScriptCore GC:
Leaks Found
WTF::HashTable::removeIterator(7,214 frames)WTF::Vector<JSC::InByVariant>::operator=(7,220 frames)JSC::SlotVisitor::drainFromShared(7,214 frames)JSC::ASTBuilder::createForOfLoop(713 frames)Related Upstream Issues
Bun Tracking Issue
Tool Created
We built an ASAN tracker (
test/asan_tracker.zig) that classifies leaks by component and auto-symbolicates. Happy to share stack traces or help coordinate upstream fixes.This confirms the WebKit Malloc growth is from JSC GC not reclaiming memory properly.
github-actions commentedon Mar 28, 2026
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.