🚨 CRITICAL: Memory leak causes freeze after 20+ minutes (15GB RAM consumption)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/20367
2. https://github.com/anthropics/claude-code/issues/21179
3. https://github.com/anthropics/claude-code/issues/20200

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

Additional Critical Data Point - OOM Kill at 15 Minutes Runtime

Timestamp: 2026-01-29 07:20:47 (just occurred)

OOM-killer log:

Out of memory: Killed process 1024 (claude)
- Total VM: 92711628kB (92.7 GB virtual)
- anon-rss: 15668896kB (15.7 GB physical RAM)
- Runtime: ~15 minutes
- Cache tokens read: Unknown (process killed before monitoring started)

Escalation:
This is now the 12th confirmed OOM kill of Claude Code in production use. The memory leak is:

• Faster: 15 minutes to OOM (vs previous 20-40 min)
• Larger: 92GB virtual memory allocation
• Blocking production work: Cannot complete multi-step tasks

Business Impact:

• Every Claude Code session lasting >15 min is at risk
• No workaround exists (memory monitoring too slow)
• Automated recovery scripts cannot prevent OOM-killer
• Linux OOM-killer terminates process forcefully (no graceful shutdown)

Request:
Please prioritize this for next release. The issue makes Claude Code unusable for serious development work on Linux.

Environment:

• OS: WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2)
• Available RAM: 16GB
• Claude version: Latest (Sonnet 4.5)

Update 2026-01-29 09:00 UTC: New Critical Bug - Agent Hang on Tool Confusion

Summary

Discovered a SECOND, SEPARATE bug that also causes memory leak + OOM-kill, distinct from the cache overflow issue.

What Happened Today (Crash #13)

Timeline:

• 07:36:31 UTC: Agent a5ae718 started
• 07:36:40 UTC: Agent attempted Skill("n8n-workflow-expert")
• 07:36:41 UTC: System returned error: Unknown skill: n8n-workflow-expert
• 07:36:41 UTC: Agent STOPPED RESPONDING (no further messages)
• 07:36:46 Local: Memory leak began (613MB → 1097MB in 10 seconds)
• 07:40:18 Local: RAM peaked at 15.1GB
• 07:40:28 Local: System recovered (OOM-kill likely occurred)

Total hang time: 4 minutes
Memory leak rate: ~5GB/min (10x faster than cache leak)
Evidence: Agent transcript agent-a5ae718.jsonl has only 7 lines, ending at the error with no recovery attempt

Root Cause: Agent Error-Handling Failure

1. Agent tried to use Skill("n8n-workflow-expert") (which doesn't exist)
2. Received correct error: Unknown skill: n8n-workflow-expert
3. Agent failed to handle the error:

• No error response written
• No recovery attempt
• No fallback behavior
• Complete hang

1. Hung agent process continued running → memory leak → OOM-kill

Note: n8n-workflow-expert exists as an agent (used with Task tool), not a skill (used with Skill tool). The agent confused the two tool types.

Comparison: Two Separate Bugs

| Aspect | Issue #21378 (Cache) | Today's Bug (Agent Hang) |
|--------|---------------------|--------------------------|
| Trigger | Cache overflow (9.6M tokens) | Wrong tool call (Skill vs Task) |
| Symptom | Gradual memory leak | Instant hang → explosive leak |
| Speed | 1-2GB per 5 min | 5GB per minute |
| Recovery | None (must restart) | None (must restart) |
| Bug Type | Cache GC failure | Agent error-handling failure |

Impact on Production Work

• Frequency: Now experiencing crashes every 20-40 minutes (up from 40-60 min)
• Blocking work: Cannot use agent system at all
• Two attack vectors: Cache leak OR agent error = both → OOM-kill
• User experience: 100% productivity loss during crashes

Technical Details

Agent transcript evidence:

// Last message in agent-a5ae718.jsonl (line 7):
{
  "type": "user",
  "message": {
    "content": [{
      "type": "tool_result",
      "content": "<tool_use_error>Unknown skill: n8n-workflow-expert</tool_use_error>",
      "is_error": true,
      "tool_use_id": "toolu_011eF5KXHAtb9S7qQm1NvsL3"
    }]
  },
  "timestamp": "2026-01-29T06:36:41.219Z"
}
// NO FURTHER MESSAGES - agent hung here

Memory monitor log:

07:36:36 - ✅ OK - RAM: 613MB
07:36:46 - ✅ OK - RAM: 1097MB  (+484MB/10s)
07:36:56 - ✅ OK - RAM: 2150MB  (+1053MB/10s)
07:37:06 - ✅ OK - RAM: 3125MB  (+975MB/10s)
07:37:36 - ⚠️  VARNING - RAM: 6156MB
07:38:16 - 🚨 KRITISKT - RAM: 10041MB
07:40:18 - 🚨 KRITISKT - RAM: 15042MB (peak before OOM)

Recommended Fix (Claude Team)

Immediate: Agent error-handling needs try/catch recovery:

// Current (BROKEN):
catch (error) {
  // No handling → agent hangs
}

// Fix:
catch (error) {
  logger.error(`Tool error: ${error.message}`)
  await agent.sendMessage(`Error occurred: ${error.message}. Continuing without this tool.`)
  return fallbackBehavior()
}

Long-term protection:

1. Agent timeout: Kill agent after 2 min no response
2. Memory limit: Kill agent if >5GB RAM
3. Force GC every 30 seconds
4. Better error telemetry

Workaround (User Side)

Temporarily disabled agent system entirely to avoid both bugs:

• No Task() calls
• No Skill() calls
• Direct tool usage only (Read, Edit, Bash)

This is not sustainable for complex work but necessary until fix deployed.

Request

Please prioritize BOTH bugs:

1. Original cache leak (#21378)
2. NEW: Agent error-handling hang

Both make Claude Code unusable for serious development on Linux. Combined, they cause crashes every 20-40 minutes.

Full technical analysis available if needed.

I'm having the same issue except it rises about 5gb per 5 seconds and then crashes down to 7gb before climbing back to 20gb
I'm happy to share nay logging if there's anything specific you'd like me to run. I tried filing a bug but the claude code freezes when running the report a bug command.
<img width="633" height="344" alt="Image" src="https://github.com/user-attachments/assets/622fd876-15a2-4dac-a429-610912a9c85e" />

Here is a way to reproduce the crash immediately. Open claude code and paste the following:

Use the Task tool to spawn a subagent with these exact parameters: - subagent_type: "general-purpose" - description: "test unknown skill" - prompt: "Call the Skill tool with skill='nonexistent-skill-xyz' and args='test'. Report any error you receive." Wait for the subagent result.

Please update the title of this bug report to reflect the fact that a crash happens immediately, not after 20 minutes.

Additional data point: Windows native (WinGet) install - same memory leak pattern

Environment:

• OS: Windows 11 Pro (build 26200)
• RAM: 32 GB
• Claude Code: v2.1.34
• Install method: WinGet (Anthropic.ClaudeCode) - native binary, no Node.js involved

Observation:

A session running for ~115 minutes accumulated 2.7 GB of resident memory before becoming completely unresponsive (frozen for 30+ minutes, no input accepted). No crash or OOM-kill occurred - the process stayed alive but non-functional.

For comparison, a fresh session launched on the same machine uses ~690 MB, meaning the frozen session grew to ~4x its initial memory footprint.

Process details (frozen session):

PID=22432 | WS=2720.6 MB | Age=115 min | Threads=34 | CPU=2158s
Binary: WinGet native package (not npm/node.js)

Key difference from original report:

• This is the native Windows binary (WinGet package), not the npm/Node.js version
• No node.exe processes involved - the leak is in the native claude.exe binary itself
• No WSL or Linux layer in the stack
• Growth rate appears slower (~18 MB/min vs the 5 GB/min reported in the agent-hang variant), suggesting the gradual cache leak rather than the explosive agent-error leak

Confirms: The memory leak is not Node.js-specific - it also affects the native Windows binary distributed via WinGet. This suggests the root cause is in shared application logic (conversation cache management), not in the Node.js runtime or Ink rendering layer.

UPDATE: RESOLVED
Updating from Claude Code _version 2.1.41 to 2.1.42_ solved the memory leak problem. The issue no longer occurs with the latest version.

---

System Details:

• OS: Linux Mint 21.1 (Kernel 5.15.0-161-generic)
• Architecture: x86_64
• RAM: 16 GB
• Claude Code Version: 2.1.41

Issue:
Experiencing severe memory leak in Claude Code that occurs even in brand new, empty project directories. Memory grows at approximately 50-60 MB/second during active conversation, leading to OOM kill within 5-15 minutes.

Reproduction:

1. Created fresh directory: mkdir ~/test-memory-leak && cd ~/test-memory-leak
2. Started Claude Code: claude
3. Had active conversation with tool calls (Read, Bash, WebFetch)
4. Monitored with: watch -n 2 "ps aux | grep claude | grep -v grep"

Observed Memory Growth:

Time      VmRSS (RAM)    Growth
00:05:33  5.67 GB        baseline
00:05:35  5.77 GB        +100 MB/2s
00:05:37  5.89 GB        +125 MB/2s
00:05:39  5.99 GB        +100 MB/2s
00:05:41  6.09 GB        +101 MB/2s

Key Findings:

• Heap allocation: 60.97 GB (VmData)
• Baseline memory on startup: 1.36 GB
• Project cache size: Only 71 KB (minimal - not the cause)
• Leak rate: 50-60 MB/second consistently
• Result: Process killed by OOM, swap exhausted (2GB/2GB)

Critical Note:
This is NOT a cache accumulation issue. The leak occurs in fresh projects with no accumulated cache, during runtime. The process heap grows unbounded during active conversation regardless of project history.

Impact:
Claude Code is currently unusable for any conversation lasting more than 5-10 minutes on a 16GB system. Multiple reproductions across different directories confirmed the same behavior.