fix: stream-parse session JSONL to prevent OOM on large sessions

[sidbmw]

Summary

Fixes #526 — happy crashes with FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory on long-running Claude Code sessions.

Root Cause

Long-running Claude Code sessions (especially after context compaction via --continue) produce JSONL files of 500MB+. Two functions load the entire file into memory:

1. readSessionLog() — uses readFile(path, 'utf-8') then .split('\n'), creating two copies of the entire file in memory
2. claudeCheckSession() — uses readFileSync(path, 'utf-8').split('\n') just to check if one valid message exists

V8's default heap limit is ~4GB. A 650MB JSONL file becomes ~1.3GB as a UTF-16 JS string, then doubles with .split(), plus the parsed JSON objects — easily exceeding the heap.

Fix

• readSessionLog(): Replace readFile() with createReadStream() + readline.createInterface() for line-by-line streaming. Memory stays flat (~50MB) regardless of file size. Also caps retained messages at 500 most recent — the mobile app only needs recent context, not the full history.

• claudeCheckSession(): Replace readFileSync() with a 16KB partial read via openSync/readSync. Only need to find one valid JSON line to confirm session validity — no need to read the entire file.

Testing

Tested with a 650MB session JSONL file (long-running Claude Code session with multiple context compactions). Before: OOM crash within 60 seconds. After: starts successfully with ~50MB memory usage.

Test plan

• Start happy --continue with a large session (500MB+ JSONL)
• Verify no OOM crash on startup
• Verify messages sync correctly to mobile app
• Verify new messages appear in real-time after initial sync
• Run existing claudeCheckSession.test.ts and sessionScanner.test.ts

🤖 Generated with Claude Code