[BUG] Bundled Bun 1.4.0 slice-index-OOB panic on macOS 26.5.1 after sleep/wake during long session (sibling of #68404)

Environment

• Claude Code: 2.1.197
• Bundled Bun: 1.4.0 (63bb0ca0d)
• macOS: 26.5.1 (production, Apple Silicon)

What happened
After a long session (~3h wall-clock), Claude Code aborted with a Bun panic. It reproducibly correlates with locking the screen / stepping away for a while, then returning and resuming the session — i.e. the Mac sleeps while a long-lived streaming connection is open, and the panic fires shortly after wake.

panic: range start index 2606904576 out of range for slice of length 220
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

Crash header (the Args: line is stripped — it only held local paths):

Bun v1.4.0 (63bb0ca0d) macOS Silicon
macOS v26.5.1
CPU: neon fp aes crc32 atomics
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) WebSocket(3) abort_signal(53) fetch(77) jsc spawn(83) standalone_executable yaml_parse(40) claude_code
Elapsed: 10704594ms | User: 84984ms | Sys: 12367ms
RSS: 0.26 GB | Peak: 0.44 GB | Commit: 122.49 MB | Faults: 162

Bun crash report: https://bun.report/1.4.0/M_163bb0camgggkE+hogCuluw6Bmkms6Bu4xp6Bu7ns6B+hu36B++y36B+6vroBuktloB284he27x3Oujw3Omms4O2193Omq+3Om5/noBm93moB2p7moB2zqx6B_A0eNorSsxLT1UoLkksKlHIzEtJrVAwMjMwszQwMTU3U8gvLVHIT1MoAqtJyy9SKM7JTE4FCeWk5qWXZCgYGRkAAMfTFT0

Relationship to #68404
Looks like a sibling of #68404 (same macOS 26.5.1 / Apple Silicon / long-session bundled-Bun crash), with three differences worth noting:

• Different panic: slice index out of range (a ~2.6e9 index into a 220-byte buffer — reads like a corrupted length field), vs #68404's null-deref at 0x0.
• Different bundled Bun: 1.4.0 here vs 1.3.14 there — the instability spans ≥2 Bun versions, so it's unlikely to be a single-version regression.
• Sharper trigger: this correlates with sleep/wake, not merely session duration. #68404 was attributed to "continuous use"; I suspect the real common factor is a sleep event during a long session, not duration alone.

The 2.6e9-into-220 index is the classic signature of parsing a length/offset field out of a buffer left in a bad state — consistent with a long-lived stream (SSE fetch / WebSocket) whose socket was frozen across sleep and mis-parsed on resume.

Related sleep/wake resilience cluster: #67186 (MCP doesn't reconnect after sleep/wake), #60104 (sleep/wake → 401 requiring reboot). This crash is the most severe of the family — a full process abort.

Requests

1. Bump the bundled Bun once the upstream slice/segfault is fixed.
2. Add app-layer sleep/wake resilience: on resume, treat a torn long-lived stream (fetch / WebSocket) as a recoverable error and reconnect, rather than letting the runtime abort the process.

Not a request, for triage: --resume <id> recovers the full conversation, so no transcript is lost — the impact is a hard interruption, not data loss.