Memory leak: Bun/WebKit Malloc unbounded growth reaching 14GB+ within minutes

Resolved 💬 4 comments Opened Mar 12, 2026 by liuzemei Closed Mar 15, 2026

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

  1. Start claude CLI
  2. Have several MCP servers configured (playwright, chrome-devtools, serena, magic, morph-fast-apply, pencil, filesystem — 7-8 total)
  3. 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

  1. The leak is NOT in MCP child processes — all child processes (serena, playwright, chrome-devtools, etc.) have stable memory (~80-185MB each, not growing)
  2. The leak is NOT in system mallocDefaultMallocZone is only 10.6MB
  3. The leak IS in Bun's WebKit Malloc — JavaScriptCore allocates 32MB chunks that accumulate and are never returned to the OS
  4. 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.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗