Memory Leak: VmPeak reaches 135GB, causes OOM kill

Memory Leak: VmPeak reaches 135GB, causes OOM kill

Summary

Claude Code 2.1.17 experiences a severe memory leak where virtual memory grows to 135GB, causing the Linux OOM killer to terminate the process.

Environment

• OS: Arch Linux (rolling)
• Kernel: Linux 6.18.6-arch1-1 x86_64
• RAM: 16GB
• Swap: Disabled (0B)
• Claude Code Version: 2.1.17

OOM Killer Event

Timestamp: Fri Jan 23 13:20:53 2026

MainThread invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=user.slice,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service/kitty-25192-0.scope,task=claude,pid=50948,uid=1000
Out of memory: Killed process 50948 (claude) total-vm:74764316kB, anon-rss:12218336kB, file-rss:1760kB, shmem-rss:3096kB, UID:1000 pgtables:24604kB oom_score_adj:0

Memory Profile Analysis

Killed Process (PID 50948)

| Metric | Value |
|--------|-------|
| total-vm | 75GB |
| anon-rss | 12GB |
| file-rss | 1.7MB |
| shmem-rss | 3MB |

Current Process After Restart (PID 54009)

| Metric | Value | Concern Level |
|--------|-------|---------------|
| VmPeak | 135GB | 🔴 CRITICAL - Historic peak |
| VmSize | 75GB | 🟡 High - Virtual memory allocated |
| VmHWM | 5.8GB | 🟡 High - Peak physical RAM |
| VmRSS | 533MB | 🟢 Normal - Current RAM usage |
| VmData | 65GB | 🔴 CRITICAL - Data segment |
| VmStk | 212KB | 🟢 Normal |
| VmExe | 56MB | 🟢 Normal |
| Threads | 18 | 🟢 Normal |
| Memory Maps | 2221 regions | 🟡 High - Many allocations |

Key Findings

1. 135GB VmPeak - This is the critical indicator. The process at some point had 135GB of virtual memory allocated, which is grossly excessive for a CLI tool.

1. 65GB VmData - The data segment (heap) is 65GB even after just 5 minutes of runtime, suggesting rapid allocation accumulation.

1. 75GB VmSize - Virtual memory allocated is 75GB while only ~500MB is resident (VmRSS), indicating sparse allocation or malloc arena fragmentation.

1. 2221 memory maps - Very high number of memory regions, consistent with many small allocations not being coalesced or freed.

1. No memory released on /clear - After running /clear, memory usage remains high.

Potential Root Causes

• Context history not being trimmed properly
• Agent subprocess artifacts retained in memory
• Token/cache accumulation without bounds
• Memory arena fragmentation (glibc malloc not releasing to OS)
• Large tool outputs retained in conversation state

Steps to Reproduce

1. Run Claude Code for an extended session (1-2 hours)
2. Use agents, file reads, and various tools
3. Run /clear - memory is not released
4. Eventually process grows until OOM killer terminates it

Impact

• Session data loss when OOM killer strikes
• Cannot use for long-running workflows
• Requires frequent restarts

Workarounds

1. Restart Claude Code every 30-60 minutes
2. Use /clear periodically (though it doesn't free memory)
3. Monitor with watch -n 5 "ps -o pid,rss,vsz,cmd -p $(pgrep claude)"

Suggested Fixes

1. Implement proper context cleanup on /clear
2. Add memory limits and monitoring
3. Investigate VmData heap accumulation (65GB)
4. Consider using jemalloc or other allocator with better fragmentation handling
5. Add periodic garbage collection of retained artifacts