Session resume causes 7.4GB ArrayBuffer leak from 2.2MB session data

Bug Report

Environment

• Claude Code version: 2.1.73
• Node.js version: v24.3.0
• Platform: Windows 11 Pro (10.0.26200)
• Shell: bash

Description

Resuming a previous session (wifi-setup-firmware-flash-debug) caused memory to spike to ~7.4 GB of ArrayBuffer allocations within 85 seconds of startup. The session data on disk is only ~2.2 MB total — a ~3,400x blowup.

The high memory warning triggered at ~6 GB. A heap snapshot and diagnostics JSON were generated automatically.

Session Details

The session being resumed was completely normal:

• 483 messages (126 user, 160 assistant, 152 progress, 23 file-history-snapshots, 18 queue-operations, 7 system)
• 4 subagent threads (2 Explore, 1 general-purpose, 1 claude-code-guide) totaling 761 KB
• 1 tool-result file at 62 KB
• Largest single message: 62 KB (a file read tool result)
• Total on-disk size: ~2.2 MB
• No unusually large payloads, serial logs, or binary data

Memory Diagnostics (from auto-generated diagnostics JSON)

{
  "memoryUsage": {
    "heapUsed": 7960260003,
    "heapTotal": 77196288,
    "external": 7957672789,
    "arrayBuffers": 7424101734,
    "rss": 2613317632
  },
  "memoryGrowthRate": {
    "bytesPerSecond": 30655367,
    "mbPerHour": 105246
  },
  "uptimeSeconds": 85.25
}

Key observations:

• V8 JS heap is tiny (77 MB) — the problem is not JS objects
• ArrayBuffers: 7.4 GB — almost all memory is in ArrayBuffers
• External memory: 7.96 GB — consistent with ArrayBuffer-backed allocations
• Growth rate: ~30 MB/s — memory grew rapidly during session restoration
• RSS: 2.6 GB — actual physical memory lower than virtual (OS hasn't committed all pages yet)

Steps to Reproduce

1. Have a session with ~483 messages / ~2.2 MB on disk (normal development session)
2. Reboot machine
3. Resume the session using claude --resume
4. Memory spikes to 6+ GB within ~85 seconds

Expected Behavior

Resuming a 2.2 MB session should not allocate 7.4 GB of ArrayBuffers. Memory usage should be roughly proportional to session size.

Hypothesis

The ArrayBuffer accumulation pattern (7.4 GB in external/ArrayBuffers vs 77 MB JS heap) suggests either:

1. Session JSONL deserialization is creating ArrayBuffers that aren't being released (e.g., streaming response buffers from re-parsing)
2. A decompression or encoding step during restore is leaking intermediate buffers
3. The conversation messages are being duplicated many times in memory during the restore pipeline

Attachments

A heap snapshot (.heapsnapshot) and diagnostics JSON were generated and are available on request. The diagnostics JSON contents are included above.