Bun panic 'range start index out of range' (~2GB accumulated state) kills long-running sessions — Bun v1.4.0 baseline, CC 2.1.197/2.1.207

Summary

Long-running claude CLI sessions (multi-day uptime, agent-style usage in tmux) crash with a Bun panic once internal accumulated state crosses ~2GB. Multiple independent sessions on the same host crashed within the same hour — the oldest/largest ones — while freshly-started sessions survived.

Panic

panic: range start index 2469998336 out of range
Bun v1.4.0 (63bb0ca0d) Linux x64 (baseline)

(2469998336 ≈ 2.47GB — looks like a 32-bit index overflow on an internal buffer.)

Environment

• Claude Code: 2.1.197 (also present in 2.1.207 — same embedded Bun v1.4.0 (63bb0ca0d) Linux x64 (baseline))
• Install: npm global (/usr/lib/node_modules/@anthropic-ai/claude-code/bin/claude.exe)
• OS: Ubuntu Linux x64 (kernel 5.4), 30GB+ RAM free at crash time
• Usage: headless/tmux interactive sessions running for days (claude --continue), large session JSONLs (300-550MB)

Evidence it is NOT OOM

• RSS of crashed processes was low (~270-600MB); host had 30GB+ free
• No OOM killer entries in dmesg, no coredumps
• Crash correlates with process AGE / accumulated state, not with memory pressure

Observed trigger

A /model switch performed on a session with a large context (~537MB JSONL) crashed it within ~1 minute; a sibling session (347MB) crashed the same minute. Model switching on inflated sessions appears to force a large reallocation that crosses the 32-bit boundary.

Workarounds we use

• Resume via "Resume from summary" instead of full session
• Periodic restarts of long-lived sessions before they accumulate ~2GB of state
• Avoid /model switches on inflated sessions

Ask

Consider building the release binary with a Bun version/build where this indexing panic is fixed, or guarding the affected buffer path for >2GB accumulated state in long-lived sessions.