Claude Code causes 49GB invisible kernel memory allocation, triggers OOM killer on 128GB system

Resolved 💬 4 comments Opened Mar 3, 2026 by KevinKickass Closed Apr 3, 2026

Summary

Claude Code CLI consumed ~49GB of kernel slab memory (invisible to all userspace monitoring tools) during a codebase analysis of a ~21k line Rust project, maxing out a 128GB RAM system and triggering the OOM killer which killed random unrelated processes. Claude Code itself survived (low RSS) while the system became unusable.

Environment

  • OS: Fedora 43, Kernel 6.17.12-300.fc43.x86_64
  • CPU: Intel i9-7940X
  • RAM: 128 GB DDR4
  • Claude Code: Latest, launched with --dangerously-skip-permissions
  • Task: Codebase analysis of a Rust editor project (~21,000 lines)

Timeline

  1. System idle at ~27GB used, ~100GB free
  2. Started Claude Code, issued a codebase analysis command
  3. RAM usage climbed to 128GB, system became unresponsive
  4. OOM killer activated — killed openclaw-gateway, plasma-discover, and other unrelated processes
  5. Claude Code stayed alive (RSS only ~440MB, OOM score too low to be targeted)
  6. Terminated Claude Code manually
  7. Immediately: 49GB freed, system back to ~24GB used, 104GB free

Root Cause

Claude Code generated 209 million anon_vma_chain kernel objects consuming ~13GB directly in slab, plus associated kernel metadata totaling ~49GB in unreclaimable slab (SUnreclaim in /proc/meminfo).

This memory is allocated by the kernel to track virtual memory area mappings on behalf of the process. It does not show up in:

  • Process RSS
  • top / htop / KDE System Monitor
  • Any standard userspace monitoring tool

The only way to detect it is via /proc/meminfo SUnreclaim field or slabtop.

Evidence

Before terminating Claude Code:

$ cat /proc/meminfo | grep Slab
Slab:           49974004 kB
SReclaimable:    1087064 kB
SUnreclaim:     48886940 kB

$ ps aux | grep claude
kevin  3562239  18.8  0.3 74979164 441484 pts/4 Sl+ claude --dangerously-skip-permissions

$ sudo slabtop -o -s c | head -8
OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
209675200 207500322 98%  0.06K  3276175  64  13104700K anon_vma_chain

After terminating Claude Code:

$ cat /proc/meminfo | grep -E "Slab|MemFree"
MemFree:       104286436 kB
Slab:            7813972 kB
SReclaimable:     522500 kB
SUnreclaim:      7291472 kB

Impact

  • Invisible resource consumption: No standard monitoring tool shows the problem. Users have no way to identify Claude Code as the cause.
  • OOM killer targets wrong processes: Since RSS is only ~440MB, the OOM killer scores Claude Code low and kills other important processes instead.
  • System-wide impact: Desktop environment, services, and daemons get killed while the actual culprit survives.

Likely Cause

Excessive mmap/munmap cycling or an extremely large number of virtual memory mappings in the Node.js runtime, causing the kernel to allocate VMA tracking structures that are never reclaimed while the process runs.

Suggested Mitigation

At minimum, document the memory behavior and suggest users run Claude Code within a cgroup memory limit:

systemd-run --user --scope -p MemoryMax=32G claude --dangerously-skip-permissions

This ensures cgroup-level memory accounting (which includes kernel slab allocated on behalf of the cgroup) limits the blast radius and the OOM killer targets the correct process.

View original on GitHub ↗

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