[BUG] CRITICAL: /clear command leaks subagent processes causing memory crashes

Resolved 💬 3 comments Opened Jan 30, 2026 by leechalot Closed Feb 3, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

### Bug Summary
The /clear command does not properly terminate subagent child processes, causing orphaned Node.js processes to accumulate across sessions. This leads to "JavaScript heap out of memory" crashes during subsequent subagent
invocations.

### Severity
CRITICAL - Causes complete session crashes and data loss for users relying on /clear for token efficiency.

### Environment

  • Claude Code Version: 2.1.25
  • Node.js Version: v22.17.1
  • Platform: Windows (running in Cursor IDE)
  • Usage History: 6+ months of stable daily usage until recently

---

### Root Cause Evidence

Process Analysis:
Running Get-Process after multiple /clear sessions revealed orphaned Node.js processes:

```
ProcessName Id MemoryMB Runtime
----------- -- -------- -------
node 16360 193.57 2 days 11 hours ← ORPHANED
node 31884 286.29 2 days 11 hours ← ORPHANED
node 2236 251.42 13 minutes ← CURRENT SESSION

Total orphaned memory: ~480 MB from 2+ days ago
```

These orphaned processes:

  • Started when user began using /clear command (recently)
  • Persist across multiple Claude Code sessions
  • Accumulate until hitting ~4GB Node.js heap limit
  • Cause crashes during new subagent invocations

---

### Crash Pattern (3 crashes documented)

Crash #1 & #2: During Navigator Agent invocation

  • Runtime: ~43 seconds into agent execution
  • Token consumption: Low (~1.8k tokens)
  • Memory exhaustion despite low computational load

Crash #3 (Most Recent): During safety-commit-tripwire agent invocation

  • Runtime: 38 seconds into agent execution
  • Context usage: 88%
  • Session cost: $0.51
  • Similar memory exhaustion pattern

Common characteristics:

  • ✅ ALL crashes occurred during subagent invocations
  • ✅ ALL happened AFTER user started using /clear regularly
  • ✅ ZERO crashes in 6 months of usage before /clear adoption
  • ✅ Crashes happen despite low token/computational activity

---

### Error Output

```
<--- Last few GCs --->

[39008:000001FDF3291000] 492510 ms: Scavenge (interleaved) 4043.4 (4132.2) -> 4041.4 (4135.9) MB, pooled: 0 MB, 9.98 / 0.00 ms (average mu = 0.301, current mu = 0.222) allocation failure;
[39008:000001FDF3291000] 494107 ms: Mark-Compact 4048.0 (4136.9) -> 4045.3 (4158.2) MB, pooled: 0 MB, 1592.21 / 0.00 ms (average mu = 0.151, current mu = 0.056) allocation failure; scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
```

Memory stats at crash:

  • Heap size: ~4GB (4048.0 MB) - hitting Node.js default limit
  • Mark-Compact mu=0.056 (severe GC pressure)
  • Multiple garbage collection failures

---

### Reproduction Steps

  1. Start fresh Claude Code session
  2. Invoke any subagent (Navigator, Code Review, etc.)
  3. Use /clear command to reset session
  4. Repeat steps 2-3 several times over multiple days
  5. Check for orphaned processes: Get-Process | Where-Object {$_.ProcessName -like "*node*"}
  6. Observe orphaned Node.js processes accumulating
  7. Eventually: New subagent invocation triggers heap exhaustion crash

---

### Timeline

Before (6+ months):

  • User always started fresh Claude Code sessions (quit and restart)
  • Zero crashes, stable operation
  • No orphaned processes

Change:

  • User started using /clear command between tasks (to save tokens on CLAUDE.md re-ingestion)
  • Noticed message about "switching from npm install to claude install" (suggests Claude Code update around this time)

After (last few days):

  • 3 crashes within days
  • All crashes during subagent execution
  • Orphaned Node.js processes confirmed running for 2+ days
  • Memory accumulation pattern confirmed

---

### Expected Behavior
When /clear command is executed:

  1. Main session conversation should be summarized
  2. All child subagent processes should be terminated
  3. Memory should be released
  4. Fresh session state with no orphaned processes

### Actual Behavior
When /clear command is executed:

  1. Main session conversation is summarized ✅
  2. Subagent child processes remain running
  3. Memory remains allocated
  4. Processes accumulate across sessions until crash ❌

---

### Impact

On Users:

  • Session crashes lose all context and work in progress
  • Unpredictable crashes (happen during critical work)
  • Users forced to choose: waste tokens (fresh sessions) OR risk crashes (/clear)
  • Defeats purpose of /clear command (meant to save tokens)

On Adoption:

  • Non-developer users lose confidence in tool reliability
  • Power users (agent-heavy workflows) hit this immediately
  • Token efficiency goals (using /clear) become liability

---

### Proposed Fix

Immediate (v2.1.26):

  1. When /clear executes, enumerate all child processes spawned for subagents
  2. Send termination signal (SIGTERM/SIGKILL) to all child processes
  3. Verify process cleanup before returning control to user
  4. Log cleanup actions for debugging: "Terminated 3 orphaned subagent processes"

Long-term:

  1. Add process lifecycle management to subagent framework
  2. Track PIDs of all spawned subagents in session metadata
  3. Implement cleanup on: /clear, session exit, crash recovery
  4. Add diagnostic command: /processes to show running subagents
  5. Add memory monitoring: warn user if >2GB accumulated across processes

---

### Workarounds (Current)

For Users:

  1. Avoid /clear for now - Use fresh sessions (quit and restart Claude Code)
  2. Kill orphaned processes manually:

``powershell
Get-Process | Where-Object {$_.ProcessName -eq "node"} | Where-Object {$_.StartTime -lt (Get-Date).AddHours(-1)} | Stop-Process -Force
``

  1. Strategic restarts: Fresh session every 3-4 tasks or before agent-heavy work
  2. Increase heap limit (insurance, not fix):

``bash
export NODE_OPTIONS="--max-old-space-size=8192"
``

---

### Test Case

```bash
# Test script to validate fix

  1. Start Claude Code
  2. Get-Process | Where-Object {$_.ProcessName -eq "node"} | Measure-Object # Count: X
  3. Invoke subagent (any type)
  4. Get-Process | Where-Object {$_.ProcessName -eq "node"} | Measure-Object # Count: X+N
  5. Run /clear command
  6. Get-Process | Where-Object {$_.ProcessName -eq "node"} | Measure-Object # Should return to X
  7. Verify: No orphaned Node.js processes remain after /clear

```

Expected result after fix:

  • Step 6 should show same process count as Step 2 (all subagent processes terminated)

---

### Additional Context

User Profile:

  • Non-developer operator managing production betting pipeline
  • Heavy subagent usage (Navigator, Code Review, Schema Guardian, etc.)
  • Token-conscious workflow (hence /clear adoption)
  • 6+ months of crash-free operation before this issue

Critical Detail:
User explicitly noted: "The whole idea behind using subagents is to free up tokens in the main session. By avoiding subagents due to crashes, I'm negating that benefit."

This bug forces users to choose between:

  • ❌ Token efficiency (/clear + subagents) → crashes
  • ❌ Stability (fresh sessions) → waste tokens on re-ingesting context

Both options are bad. Fix needed urgently.

---

### Request for Anthropic Team

  1. Priority: Treat as P0/Critical (causes data loss and session crashes)
  2. Timeline: Fast-track fix in next patch release (2.1.26)
  3. Validation: Provide test build for user to validate fix before release
  4. Communication: Update release notes with "/clear memory leak fix" for visibility
  5. Diagnostics: Add /processes or similar command to help users identify orphaned subagents

---

### Attachments

Available upon request:

  • Full crash stack traces (all 3 incidents)
  • Process dumps showing orphaned Node.js processes
  • Session transcripts leading up to crashes
  • Memory growth patterns across multiple /clear sessions

Prepared to test:

  • Beta builds with proposed fix
  • Alternative cleanup strategies
  • Diagnostic tooling

---

Reporter: Non-developer user (via Claude Code assistance)
Reproducible: Yes (100% reproducible with process analysis)
Regression: Yes (started recently, likely tied to Claude Code update around "npm install → claude install" migration)

---

What Should Happen?

Subagents should be able to be invoked in a session without erroring/crashing, regardless of whether the session was begun from scratch or via the /clear command.

Error Messages/Logs

Steps to Reproduce

### Reproduction Steps

  1. Start fresh Claude Code session
  2. Invoke any subagent (Navigator, Code Review, etc.)
  3. Use /clear command to reset session
  4. Repeat steps 2-3 several times over multiple days
  5. Check for orphaned processes: Get-Process | Where-Object {$_.ProcessName -like "*node*"}
  6. Observe orphaned Node.js processes accumulating
  7. Eventually: New subagent invocation triggers heap exhaustion crash

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.25

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Cursor

Additional Information

_No response_

View original on GitHub ↗

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