Memory leak: RSS grows to ~6 GB on ARM64 in 2.1.121 (regression similar to #28763)

Status Fixed / completed

Reported on v2.1.121

Maintainer reply None cached

Activity 4 comments · opened Apr 29, 2026 · closed Apr 29, 2026

Summary

Same memory leak pattern as #28763 has reappeared in 2.1.121. The claude process grows unbounded and is killed by the OOM killer within 30–60 minutes of an active session. #28763 was reported fixed in 2.1.58 — this is a fresh regression on a later version.

Environment

Claude Code: 2.1.121
Node: v20.19.2
npm: 9.2.0
OS: Debian 13 (trixie), Linux 6.12.75+rpt-rpi-2712
Arch: aarch64 (Raspberry Pi 5, 8 GB RAM, 2 GB swap)
Model: claude-opus-4-7[1m] (Opus 4.7, 1M context tier)

Repro

Normal usage — read/edit files, multi-turn coding session on a small repo. Within ~30–60 minutes the OS kills the claude process. Restart, repeat, same outcome.

Evidence (dmesg, 5 consecutive OOM kills)

Out of memory: Killed process 3695213 (claude) total-vm:75207488kB, anon-rss:5914480kB
Out of memory: Killed process 3695820 (claude) total-vm:75207536kB, anon-rss:5912752kB
Out of memory: Killed process 3697675 (claude) total-vm:75174704kB, anon-rss:5908048kB
Out of memory: Killed process 3698554 (claude) total-vm:75207552kB, anon-rss:5952128kB
Out of memory: Killed process 3699091 (claude) total-vm:75240240kB, anon-rss:5942944kB

Every kill: virtual ~75 GB, RSS ~5.9 GB. RSS is consistent across runs which suggests the leak grows until the OOM-killer fires at roughly the same point relative to total system memory.

Notes

Started after an auto-update yesterday — system had been stable on a prior version for weeks before this.
ARM64-specific? Possibly — original issue had platform:wsl label, but the failure mode (unbounded heap growth → OOM) is identical.
1M-context tier may amplify it but probably not the root cause; growth pattern suggests an ArrayBuffer / heap accumulation that doesn't release.

References: #28763, #27421

View original on GitHub ↗

4 Comments

github-actions[bot] · 5 months ago

Found 3 possible duplicate issues:

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

0xbrainkid · 5 months ago

This is long-run stability failure at the process-residency layer.

If RSS grows to ~6 GB on ARM64 in 2.1.121 with a regression pattern similar to #28763, then the system is not just getting slower over time — it is converting ordinary session duration into a resource-exhaustion risk.

Why it matters:

long-running coding sessions are normal, so time-based memory growth hits regular workflows rather than edge cases
once RSS climbs high enough, users see degraded performance, OS pressure, and eventually secondary failures that obscure the root cause
regression similarity suggests a known failure mode may have re-entered through a new path

I would want clarity on:

whether the retained memory is in transcript/history structures, renderer state, tool outputs, or background session bookkeeping
whether growth is tied to specific actions like diff rendering, tool usage, or compaction cycles
whether the product can expose a lightweight live memory breakdown so users can correlate growth with actual session behavior

Reliability is not just correctness per turn. If normal session duration steadily converts into multi-GB RSS growth, the persistence model becomes operationally untrustworthy.

ernens · 5 months ago

Closing as duplicate of #54200 — same regression in the 2.1.118+ window on Linux. Technical data and ARM64-specific evidence moved to #54200 (https://github.com/anthropics/claude-code/issues/54200#issuecomment-4341780761) so it stays in one thread.