[BUG] Memory leak + Swap growth — Claude Code Sonnet 4.6 kills sessions in ~8 min (v2.1.49)

Resolved 💬 5 comments Opened Feb 21, 2026 by RonaldPrecieux Closed Mar 22, 2026

[BUG] Memory leak + Swap growth — Claude Code Sonnet 4.6 kills sessions in minutes

Date: 2026-02-21
Reporter: Linux user, collected via automated SRE monitoring
Claude Code version: 2.1.49
Severity: Critical — tool is barely usable; sessions die every 8–13 minutes

---

Environment

| Key | Value |
|-----|-------|
| OS | Ubuntu 22.04 LTS |
| Kernel | 6.8.0-100-generic |
| RAM | 16 GB total / ~7.7 GB available at session start |
| Swap | 8 GB (swapfile, /swapfile) |
| CPU load avg | 3.23 / 4.71 / 3.97 |
| Claude Code version | 2.1.49 (Claude Code) |
| MemoryMax (systemd scope) | 6 GB (earlier sessions) → 10 GB (after bashrc update) |
| Launch method | systemd-run --user --scope -p MemoryMax=Xg claude |
| Uptime at report | 4h15m |

---

Observed Behavior

Claude Code's memory usage (RSS) grows continuously and rapidly from ~300 MB at launch to the MemoryMax ceiling within 8–13 minutes. The process is then killed by either:

  1. Kernel OOM killer (memcg constraint) — when RSS hits MemoryMax
  2. systemd-oomd — when userspace memory pressure exceeds 50–86% for >20s

Additionally, the kernel OOM reports ~7 GB of swap entries (swapents) in use at kill time — far beyond what a CLI tool should require. This indicates a concurrent RAM leak and swap growth issue.

Sessions are too short to be productive. The tool restarts ~8–10 times in 2 hours.

---

Crash Timeline — 2026-02-21 (today)

All kills confirmed from journalctl kernel + systemd-oomd logs:

| Kill time | PID | RSS at kill | swapents (pages→GB) | Kill cause | Session started | Duration |
|-----------|-------|-------------|----------------------|------------|-----------------|----------|
| 12:37:53 | 9867 | 5.95 GB | 1,819,904 → ~6.95 GB | kernel OOM (memcg 6GB) | 12:27:28 | ~10 min |
| 12:55:30 | — | >56% system | — | systemd-oomd | 12:42:01 | ~13 min |
| 13:09:53 | 12718 | 5.97 GB | 1,825,472 → ~6.97 GB | kernel OOM (memcg 6GB) | 13:01:26 | ~8 min |
| 13:19:50 | 13271 | 6.02 GB | 1,826,943 → ~6.97 GB | kernel OOM (memcg 6GB) | 13:18:19 | ~1.5 min|
| 13:29:25 | 13688 | 5.97 GB | 1,827,432 → ~6.97 GB | kernel OOM (memcg 6GB) | ~13:20 | ~9 min |
| 13:42:31 | 14519 | 5.83 GB | 1,831,360 → ~6.99 GB | kernel OOM (memcg 6GB) | 13:37:30 | ~5 min |
| 13:55:09 | — | 86% pressure| — | systemd-oomd | 13:45:08 | ~10 min |
| 14:07:14 | — | 73% pressure| — | systemd-oomd | 13:56:02 | ~11 min |
| 14:16:11 | — | 73% pressure| — | systemd-oomd | 14:07:34 | ~8 min |

Total kills on 2026-02-21: 9 sessions in ~2 hours
Average session duration: ~8.3 minutes

---

Raw Kernel OOM Events

12:37:53 kernel: Memory cgroup out of memory: Killed process 9867 (claude)
  total-vm:74926044kB, anon-rss:6095352kB, file-rss:37376kB, swapents:1819904

13:09:53 kernel: Memory cgroup out of memory: Killed process 12718 (claude)
  total-vm:74870336kB, anon-rss:6114484kB, file-rss:37760kB, swapents:1825472

13:19:50 kernel: Memory cgroup out of memory: Killed process 13271 (claude)
  total-vm:74878428kB, anon-rss:6169088kB, file-rss:49792kB, swapents:1826943

13:29:25 kernel: Memory cgroup out of memory: Killed process 13688 (claude)
  total-vm:74906228kB, anon-rss:6108972kB, file-rss:49792kB, swapents:1827432

13:42:31 kernel: Memory cgroup out of memory: Killed process 14519 (claude)
  total-vm:74845688kB, anon-rss:5967064kB, file-rss:49408kB, swapents:1831360

Notable:

  • total_vm consistently ~71–75 GB (virtual address space — massive for a CLI tool)
  • anon-rss consistently hits ~5.97–6.17 GB before kill
  • swapents consistently ~1.82–1.83 million pages = ~7 GB of swap used per session

---

Live Monitoring Data

Monitoring started at 14:20:56 on new session (MemoryMax=10 GB).
Data collected every 30s into /tmp/claude-memory-log.csv:

timestamp,pid,VmRSS_MB,VmSwap_MB,MemCurrent_MB,RAM_free_MB,Swap_free_MB,MemMax_MB

(Log file at /tmp/claude-memory-log.csv — populated during 10-min background monitoring)

Snapshot at session start (14:20):

  • MemoryCurrent = 1,537 MB (fresh session)
  • MemoryMax = 10,240 MB (10 GB)
  • RAM free = ~3,700 MB
  • Swap used = ~922 MB (system-wide)

---

Growth Rate Analysis

From OOM kernel data and session durations:

| Metric | Value |
|--------|-------|
| RSS at session start | ~300–500 MB (estimated) |
| RSS at kill | ~5,970–6,170 MB |
| Average session duration | ~8.3 minutes |
| RAM growth rate | ~630–680 MB/min |
| Swap at kill (swapents) | ~6.95–6.99 GB per session |
| Swap growth rate | Reaches ~7 GB within session lifetime |
| Average RSS at kill | ~5,980 MB |

---

systemd-oomd Events

12:55:30 systemd-oomd: Killed scope (memory pressure 56.06% > 50% for >20s)
13:55:09 systemd-oomd: Killed scope (memory pressure 86.47% > 50% for >20s)
13:55:24 systemd-oomd: Killed scope (memory pressure 82.38% > 50% for >20s)
13:55:40 systemd-oomd: Killed scope (memory pressure 73.54% > 50% for >20s)
14:07:14 systemd-oomd: Killed scope (memory pressure 73.36% > 50% for >20s)
14:16:11 systemd-oomd: Killed scope (memory pressure 73.60% > 50% for >20s)
14:16:26 systemd-oomd: Killed scope (memory pressure 73.57% > 50% for >20s)
14:16:41 systemd-oomd: Killed scope (memory pressure 66.35% > 50% for >20s)
14:16:56 systemd-oomd: Killed scope (memory pressure 63.59% > 50% for >20s)

Sessions were also killed via systemd-oomd before hitting MemoryMax, suggesting global system memory pressure caused by claude's leak.

---

Earlier Events (overnight 2026-02-21 00:00–02:00)

01:17:56 systemd-oomd: Killed terminal scope (pressure 89.18% > 50%)
01:18:11 systemd-oomd: Killed terminal scope (pressure 82.72% > 50%)
11:38:47 systemd-oomd: Killed terminal scope (pressure 65.87% > 50%)

Terminal processes were collateral damage from claude's memory pressure.

---

Current Workaround (Insufficient)

# In ~/.bashrc:
alias claude='systemd-run --user --scope -p MemoryMax=10G claude'
  • At 6 GB limit: sessions lasted ~8–13 min before kill
  • At 10 GB limit: expected improvement is marginal given ~630 MB/min growth rate
  • Estimated session duration at 10 GB: ~15–18 min (still too short)
  • At 14 GB: ~20–25 min
  • There is no MemoryMax value that fixes a leak growing at 630 MB/min

---

Impact

  • Workflow completely disrupted — cannot complete any task longer than ~8 minutes
  • Sessions killed mid-operation, leaving incomplete work
  • System-wide memory pressure kills other processes (terminal, tracker-miner) as collateral
  • User must constantly restart sessions and re-explain context
  • 9+ forced restarts in a single 2-hour work session

---

Suspected Root Cause

Based on the data:

  1. Heap/context buffer leak: total_vm of ~71 GB and continuous anonymous RSS growth suggests unbounded heap or context window buffer accumulation
  2. Swap pre-allocation: swapents reaching ~7 GB (nearly the full 8 GB swapfile) before kill suggests swap is being aggressively mapped/not released between operations
  3. No GC or memory cap: The process does not appear to release memory between API calls or conversation turns

This regression appears to have started around the Sonnet 4.6 release (~Feb 15, 2026). Earlier versions did not exhibit this behavior at this severity.

---

Explicit Request

  1. Fix the RAM memory leak in Claude Code 2.1.49 / Sonnet 4.6 — unbounded RSS growth must be addressed
  2. Fix the swap growth issue — swapents reaching ~7 GB per session is abnormal
  3. Add internal memory management — GC, context trimming, or soft memory cap before process termination
  4. Provide a --memory-limit flag as interim workaround allowing graceful degradation instead of hard kill

---

Reproduction

  1. Install Claude Code 2.1.49 on Linux with 16 GB RAM + 8 GB swap
  2. Run: systemd-run --user --scope -p MemoryMax=6G claude
  3. Start any multi-turn conversation or coding task
  4. Monitor: watch -n5 "systemctl --user show \$(systemctl --user list-units | grep run- | grep scope | awk '{print \$1}' | head -1) | grep -E 'MemoryCurrent|MemoryMax'"
  5. Observe: MemoryCurrent grows ~630 MB/min until process is killed

---

Bug report generated automatically via SRE monitoring script on 2026-02-21.

View original on GitHub ↗

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