[BUG] All running sessions segfault simultaneously on macOS wake from deep sleep (Bun 1.4.0 GC socket finalizer, SIGSEGV at 0x4)

[BUG] All running sessions segfault simultaneously on macOS wake from deep sleep (Bun 1.4.0 GC socket finalizer, SIGSEGV at 0x4)

Summary

All 5 concurrently running Claude Code sessions on one Mac crashed with an identical segfault within 0.5 s of each other, ~36 s after the machine did a DarkWake (Power Nap maintenance wake) from Deep Idle standby. The crash is a null-pointer dereference (address 0x4) inside Bun's GC finalization of a socket object.

Environment

• Claude Code 2.1.212 (native installer, ~/.local/share/claude/versions/2.1.212)
• Bun v1.4.0 (a505a2999), bundled (same Bun in 2.1.207–2.1.212)
• macOS 26.3 (25D125), MacBook Pro M1 Max (MacBookPro18,2), arm64
• Terminal: WezTerm; sessions idle at prompt, on battery

Timeline (from pmset -g log + crash reports)

| Time (UTC+3) | Event |
|---|---|
| ~21:26 | Mac enters deep standby (hibernatemode 3) |
| 22:41:00 | DarkWake from Deep Idle [CDNP] : due to smc.sysState.Wake(0x70070000) wifibt |
| 22:41:36.14–22:41:36.67 | All 5 Claude Code processes SIGSEGV (pids 31197, 32745, 34863, 60430, 60859 — launched hours apart: 13:16–20:17) |
| 22:41:45 | Mac re-enters sleep (Maintenance Sleep) |

Crash details

macOS crash reports: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS at 0x0000000000000004, faulting frames byte-identical across all 5 processes (same image offsets 0x5535e0 0x5535e0 0x10b79c4 0xf52960 0x27d47e0 …), with _sigtramp in the stack (Bun's own segfault handler → raise).

Decoded bun.report trace:

JSC::JSLockHolder::JSLockHolder (JSLock.cpp)
Bun__JSValue__unprotect (bindings.cpp)
unprotect (JSValue.rs)
Handlers::drop (Handlers.rs)            <- socket handler cleanup
NewSocket<true>::deinit_and_destroy (socket_body.rs)
JSC::Subspace::destroy (Subspace.cpp)
Heap: sweepPreciseAllocations / finalize
us_loop_run_bun_tick
Run::start (run_command.rs)

bun.report URL from one crashed session:
https://bun.report/1.4.0/M_1a505a29mgkgkEuhogD2p234C+960Km88thB+100e+9j1vCu/+lvCulpkvCm6olvC++nkvCms+uvCm4jzvC2kjmvCut64O2xvyf++sjcumsihB+81zKmq2jgB2wmigB+uyjTA2AI

Analysis

During the long standby the sessions' long-lived sockets (API/telemetry/MCP connections) died. On the maintenance wake the event loop ran briefly, dead socket objects were torn down, and the GC sweep finalized a NewSocket whose handler unprotect path dereferenced a null/freed JSC VM pointer (0x4 = field at offset 4 of a null struct). Because every session held the same kind of dead sockets and woke at the same instant, all five crashed simultaneously with identical stacks.

Side effects observed:

• Terminal left with SGR mouse tracking enabled (mouse movement spewed 35;45;17M… sequences into the shell after the crash).
• "Auto-update failed · Run claude doctor" shown in one pane — presumably the update check hit the flapping DarkWake network (2.1.212 was already the latest at the time).

Repro

Not attempted deliberately, but conditions were: multiple idle sessions → deep standby on battery → Power Nap maintenance wake. First occurrence on this machine (no prior segfault reports; same Bun 1.4.0 since 2.1.207).

Full .ips crash reports (5) available on request.