JavaScript heap out of memory crash after extended session (~128k tokens)

Description

Claude Code crashed with JavaScript heap out of memory error after an extended session (~9 hours based on GC timestamps).

Environment

• Claude Code version: 2.0.53
• Model: claude-opus-4-5-20251101
• Node.js: 25.1.0 (Homebrew on macOS ARM64)
• OS: macOS (Apple Silicon)
• System RAM: 64 GB (plenty of free memory available at crash time)

Session Info at Crash

• Context tokens: ~128,000
• Session cost: ~$15
• Heap at crash: 4640 MB (limit ~4.7GB)

Key Issue: Artificial Memory Limit

The machine has 64GB RAM with significant free memory available, but Node.js hit its default heap limit (~4GB on ARM64). Claude Code could benefit from:

1. Setting --max-old-space-size to allow larger heaps on high-memory machines
2. Or detecting available system memory and adjusting accordingly

Crash Details

The crash occurred during a String.prototype.split() operation, suggesting memory exhaustion while processing a large string.

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

----- Last few GCs -----
[89909:0x74e80c000] 33397980 ms: Scavenge (during sweeping) 3881.6 (4009.9) -> 3881.6 (4011.9) MB, pooled: 0.0 MB, 19.73 / 0.00 ms (average mu = 0.950, current mu = 0.955) allocation failure;
[89909:0x74e80c000] 33398316 ms: Mark-Compact (reduce) 4728.3 (4830.6) -> 4640.8 (4679.5) MB, pooled: 0.0 MB, 17.93 / 0.00 ms

----- Native stack trace -----
 1: node::OOMErrorHandler
 2: v8::Utils::ReportOOMFailure
 3: v8::internal::V8::FatalProcessOutOfMemory
 4-10: [heap allocation internals]
11: v8::internal::Factory::NewJSArray
12: v8::internal::Runtime_StringSplit
13: Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit
14: Builtins_StringPrototypeSplit
    [... JIT frames ...]

Reproduction

• Long-running session (multiple hours)
• High token count approaching context limit
• Session involved multiple Task tool agent spawns and file operations

Expected Behavior

Claude Code should gracefully handle memory pressure, potentially:

• Increase default heap limit on high-memory machines (e.g., --max-old-space-size=8192 or higher)
• Warn user when approaching heap limits
• Offer to start fresh session
• Implement memory pressure handling

Notes

• GC was running frequently (mu = 0.95) indicating heavy allocation pressure
• Crash point at StringPrototypeSplit suggests large string processing
• No user action triggered the crash - it happened mid-session
• System had ~28GB+ free memory at similar time, but Node couldn't use it