Claude Code crashes with SIGABRT when session JSONL files exceed V8 heap limit

Description

Claude Code crashes on startup with SIGABRT when historical session files grow too large. The crash occurs because Claude attempts to parse entire session JSONL files using V8's JSON.parse, which fails when files exceed the V8 heap limit.

Environment

• OS: Fedora Linux (kernel 6.x)
• Claude Code version: 2.1.12

Steps to Reproduce

1. Use Claude Code extensively in a project over time
2. Session JSONL files in ~/.claude/projects/<project-hash>/ grow to multiple gigabytes
3. Attempt to start Claude Code in that project directory
4. Claude immediately crashes with SIGABRT

Observed Behavior

• Claude uses ~13GB RAM on startup before crashing
• Process receives SIGABRT signal
• Core dump shows V8 OOM during JSON parsing

Stack Trace (from coredump)

#0  abort (libc.so.6)
#1  node::OOMErrorHandler
#2  v8::Utils::ReportOOMFailure
#3  v8::internal::V8::FatalProcessOutOfMemory
...
#14 v8::internal::JsonParser::MakeString
#15 v8::internal::JsonParser::ParseJsonValue
#17 v8::internal::Builtin_JsonParse

Root Cause

Session JSONL files (e.g., <uuid>.jsonl) grew to 4.9GB and 3.5GB. On startup, Claude attempts to parse these files entirely into memory, exceeding V8 heap limits.

Workaround

Manually remove or move large session files from ~/.claude/projects/<project-hash>/:

# Find large session files
find ~/.claude/projects -name "*.jsonl" -size +500M

# Move them out of the way
mv ~/.claude/projects/<project-hash>/<large-file>.jsonl /tmp/

Claude starts normally after removing the large files.

Expected Behavior

• Session files should have size limits or automatic rotation
• Large session files should be streamed/parsed incrementally, not loaded entirely into memory
• On startup failure due to session data, Claude should offer recovery options (clear session, skip loading, etc.)
• At minimum, a clear error message instead of SIGABRT crash

Additional Context

• The same Claude binary works fine in other project directories with smaller session files (~500MB RAM usage)
• The crash is reproducible and deterministic for affected projects
• Restoring the large session files causes the crash to return