Memory spike: 3 processes peaked at 12.7 GB combined on 18 GB machine (v2.1.34, macOS native)

[Piesson]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report
• I am using the latest version of Claude Code

What's Wrong?

Three Claude Code processes spiked to a combined peak of 12.7 GB on an 18 GB machine (71% of total RAM). System swap hit 96%.

This is not a team/multi-agent session. Just normal single-user work — reading files, editing code, running tools.

The Numbers

Captured with footprint -p claude --swapped on Feb 8, 2026:

Peak memory per process:

PID	Current	Peak	Top Consumer
97354	4,414 MB	5,810 MB	WebKit malloc: 3,057 MB
94672	1,597 MB	3,715 MB	WebKit malloc: 850 MB
63744	2,276 MB	3,215 MB	WebKit malloc: 1,738 MB
3 others	1,015 MB	~1,200 MB	—
Total	9,301 MB	~12,740 MB	WebKit malloc: 6,381 MB

Two additional problems:

• Zombie processes found: PID 64816 alive for 16 days, PID 28807 alive for 26 days. These sessions ended long ago but the processes never exited.
• Swap nearly full: 24,581 / 25,600 MB used (96%). Swapins: 765M.

Root Cause Hint

WebKit malloc is responsible for 6.3 GB out of 9.3 GB total dirty memory. IOAccelerator (GPU) adds another 2.3 GB. These two categories alone account for 93% of all memory used.

This suggests the WebView layer is not releasing DOM/rendering memory between conversation turns or after context compaction.

Environment

• Claude Code: 2.1.34 (native macOS app)
• macOS: 26.1 (Tahoe, Build 25B78)
• Chip: Apple M3 Pro
• RAM: 18 GB
• Model: Opus 4.6 (1M context)

Steps to Reproduce

1. Use Claude Code native for a few hours across multiple sessions
2. Run footprint -p claude --swapped
3. Observe memory growth and zombie processes

Workaround

pkill -9 claude reclaims all memory.

Related Issues

• [BUG] High memory usage (~13-16 GB) when using Team/Teammate mode #23883 — 13-16 GB in Team mode (Windows, v2.1.34)
• [BUG] Memory leak: API clients created repeatedly instead of reused (8-9 GB memory usage) #22162 — API client leak (macOS, high-priority)
• Claude Code Memory Leak - Process Grows to 120+ GB RAM and Gets OOM Killed #4953 — 120+ GB OOM kill (Linux, oncall)

[github-actions]

Found 3 possible duplicate issues:

1. [Memory Leak] Claude Code 2.1.19 consuming ~12GB RAM on macOS 15.5 #23252
2. Memory explosion (400MB → 14GB) when subagent invokes Skill tool - WebKit Malloc leak #21965
3. [BUG] VSCode Extension 2.1.20 - Critical Memory Leak: 11.6GB per conversation window on macOS #21182

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[Piesson]

Not a duplicate — this report covers a different version, platform, and trigger from all three flagged issues, and provides new diagnostic data.

	This issue (#24113)	#23252	#21965	#21182
Version	2.1.34 (latest)	2.1.19	2.1.25	2.1.20
Platform	Native macOS CLI	npm CLI	npm CLI (macOS)	VSCode extension
Trigger	Normal single-user usage	Normal usage	Subagent → Skill tool	Opening conversation window
macOS	26.1 (Tahoe)	15.5	26.3	unspecified

What this issue adds that the others don't:

1. Still happening on v2.1.34 — confirms the leak is not fixed across 4 versions (2.1.19 → 2.1.34)
2. footprint profiling with malloc zone breakdown — WebKit malloc alone accounts for 6.3 GB out of 9.3 GB dirty. This points directly at the WebView rendering layer, not Node.js or the npm CLI process
3. Zombie processes — PIDs alive for 16 and 26 days after sessions ended. This is a separate process lifecycle bug not mentioned in any of the three issues
4. Native CLI, not npm CLI or VSCode — different runtime (Electron-based native app vs Node.js), same memory behavior

If anything, this report strengthens the case that the WebKit malloc leak is a cross-platform, cross-version systemic issue — not limited to one trigger or one version.

[Piesson]

Update: Root cause identified — this is a Ghostty terminal bug, not Claude Code

After further investigation, the memory consumption I reported was caused by a memory leak in Ghostty (my terminal emulator), not Claude Code itself.

Root cause: Ghostty has a bug in scrollback pruning where non-standard pages are resized to standard size, causing munmap to never be called. Claude Code's output (heavy multi-codepoint grapheme sequences) triggers this leak at scale.

References:

• ghostty-org/ghostty#10289 — Same symptoms (71 GB on 16 GB machine)
• Mitchell Hashimoto's detailed write-up
• Fix PR #10251

Status: Fixed on Ghostty's main branch. Will ship in Ghostty 1.3.0 (expected March 2026). Workaround: scrollback-limit = 2500 in Ghostty config.

Apologies for the noise — closing this issue.

[Piesson]

Closing — root cause is Ghostty memory leak, not Claude Code.