# [BUG] Extreme memory and CPU usage on WSL2 causing system instability

Same here

• Claude CLI 2.1.58 ~9.6 GB RSS in a short, fresh session
• WSL2 on AMD, 16 GB total RAM, memory=10GB, swap=4GB
• Kernel OOM-killed the process after exhausting all swap

<img width="1888" height="235" alt="Image" src="https://github.com/user-attachments/assets/f19c9ae8-f0b1-402b-8d9e-6c01c8681355" />

same here, even I do nothing just keep the claude code open

WSL2 on Intel, 32 GB total RAM, Claude CLI 2.1.68

• 1st try: WSL configured memory=8GB, swap=8GB, after using claude for 1~2 rounds, the WSL hangs, I have to run wsl --shutdown and restart WSL.
• 2nd try: WSL configured memory=16GB, swap=8GB, claude for 10+ rounds, %MEM grows to 90%+, the WSL hangs but soon recovers, I found claude Killed by OS.
• 3rd try: WSL configured memory=24GB, swap=8GB, claude for 30+ rounds, %MEM is 50%~60%, the WSL doesn't hang any more, however after I'm back from a sleep, the claude process was Killed by OS, not sure when. UPDATE: claude says High memory usage (19.8GB) and Killed.

WSL2 on Intel, 32 GB total RAM, Claude CLI 2.1.68 * 3rd try: WSL configured memory=24GB, swap=8GB, claude for 30+ rounds, %MEM is 50%~60%, the WSL doesn't hang any more, however after I'm back from a sleep, the claude process was Killed by OS, not sure when. UPDATE: claude says High memory usage (19.8GB) and Killed.

I'm surprised it goes up to 40+GB, a /compact doesn't help. As requested by claude, I've run /heapdump, the result are as follows:
3c2ba436-f939-4b5d-aef7-54be951b2eea-diagnostics.zip

Environment:

• Claude Code: 2.1.72, Claude Opus 4.6
• OS: WSL2 Ubuntu on Windows (kernel 6.6.87.2)
• CPU: AMD Ryzen 5 7520U
• RAM: 7.4GB total WSL allocation (no custom .wslconfig memory limit)
• Node: v20.19.5
• Terminal: VS Code Remote - WSL

Observations:

• Fresh session (~3 min in): claude already at 74.8GB VIRT / 761MB RSS / 62% CPU
• Several MCP servers running (Playwright, Firecrawl, Sequential Thinking) adding ~400MB combined
• VS Code file watcher consuming 519MB at 88% CPU, competing for the same limited RAM
• Two heap snapshots generated: 32MB and 44MB (/heapdump)
• With only 7.4GB WSL RAM, OOM kills happen quickly — makes Claude Code unusable for extended sessions

Additional note: The low WSL memory default (50% of host RAM on systems with ≤16GB) makes this issue especially severe for users who haven't tuned .wslconfig. Even users with 16GB physical RAM only get ~8GB in WSL by default, which the claude process can exhaust in minutes.

Follow-up — possible AMD correlation:

Looking at the reports so far, both AMD users seem to hit the memory blow-up faster/harder:

| User | CPU | WSL RAM | Outcome |
|------|-----|---------|---------|
| @timorieber | AMD | 10GB | OOM-killed in a short, fresh session (9.6GB RSS) |
| me (Josep) | AMD Ryzen 5 7520U | 7.4GB | 74.8GB VIRT within ~3 min of fresh session |
| @evisong | Intel | 8-24GB | Survives longer (10-30+ rounds before OOM) |
| OP @furkanakkurt1335 | Intel i7-13700HX | 24GB | Grows over ~10 min from 4.7GB to 21.1GB |

AMD users appear to reach critical memory levels significantly faster than Intel users with comparable setups. Could be coincidence with small sample size, but worth investigating whether there's a platform-specific code path (e.g. V8/Node memory allocation behavior differing on AMD).

Another data point — regression accelerating over versions:

From my experience (AMD Ryzen 5 7520U, WSL2, 7.4GB RAM): last week the memory issue was present but manageable — sessions could run for a reasonable time. This week (v2.1.72) it's hitting critical levels within minutes of a fresh session. The problem seems to be getting worse with each release, not just present.

The original reporter also noted: "this happens only lately" and marked it as a regression. Combined with the version progression visible in comments (2.1.58 → 2.1.68 → 2.1.72), the leak appears to be worsening across updates.

Analysis: Memory growth is proportional to cumulative usage, not just session time

Adding some data from investigating locally. The theory: this isn't just a within-session leak — it's cumulative across sessions. The more you've used Claude Code historically, the worse each new session behaves.

Evidence:

1. Local storage accumulation: My ~/.claude/ directory is 1.1GB total:

• projects/ — 893MB (session JSONL files + tool-results from past sessions)
• debug/ — 117MB
• telemetry/ — 40MB
• file-history/ — 28MB

This data accumulates with each session and is never pruned. If Claude Code loads/indexes this on startup or during operation, it explains the baseline memory being higher for heavy users.

1. "Idle" growth explained: @suguanYang reports memory growing even idle. This is consistent: the process isn't truly idle — it has MCP servers, file watchers, and background indexing operating on an ever-larger data set. More historical data → more work even when "idle."

1. "Faster today than yesterday": From my experience — memory grows faster in new sessions compared to earlier in the week. Same hardware, same WSL config. The only variable that changed is the accumulated state in ~/.claude/. Yesterday's session added more data → today's session starts with a bigger footprint and grows faster.

1. /compact doesn't help (@evisong confirmed): This makes sense — /compact trims conversation context, but the accumulated project data, tool-results, debug logs, and telemetry remain fully loaded/referenced.

The pattern:

• Fresh install → manageable memory, slow growth
• After days/weeks of heavy use → 1GB+ of accumulated local data → higher baseline RSS, faster growth, quicker OOM on WSL
• WSL's memory ceiling (often just 50% of host RAM by default) makes this fatal much sooner than on native Linux/Mac

Suggested investigation for the team:

• Are past session JSONL files and tool-results loaded into memory on startup or during session resume?
• Is there an unbounded cache/map that indexes historical sessions?
• The heapdump from @evisong should show which objects are retaining the most memory

Environment: Claude Code 2.1.72, WSL2, AMD Ryzen 5 7520U, 7.4GB WSL RAM, Node v20.19.5

Update: Since Claude Code v2.1.74 it's running ok, I no longer have this problem. Thanks a lot to the team.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.