Bun 1.3.10 segfault on Windows x64 — JSC GC use-after-free persists from #21875 #27003

Summary

Claude Code v2.1.47 (Bun v1.3.10) crashes with a segmentation fault at address 0xFFFFFFFFFFFFFFFF on Windows 11 x64 during normal multi-subagent orchestration. This is the same JSC GC use-after-free crash family documented in #21875, confirming the Bun update from 1.3.5 → 1.3.10 did not resolve the underlying issue.

Environment

Crash Output

Bun v1.3.10 (1423d3c8) Windows x64 (baseline)
Windows v.win11_dt
CPU: sse42 avx avx2
Args: "C:\Users\oimir\.local\bin\claude.exe" "--dangerously-skip-permissions" "-d"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) abort_signal(3128) fetch(1649) jsc spawn(3245) standalone_executable process_dlopen(2) yaml_parse(29600)
Builtins: "bun:main" "node:assert" "node:async_hooks" "node:buffer" "node:child_process" "node:constants" "node:crypto" "node:events" "node:fs" "node:fs/promises" "node:http" "node:https" "node:module" "node:net" "node:os" "node:path" "node:path/posix" "node:path/win32" "node:perf_hooks" "node:process" "node:stream" "node:timers/promises" "node:tls" "node:tty" "node:url" "node:util" "node:zlib" "node:worker_threads" "undici" "ws" "node:http2"
Elapsed: 49843559ms | User: 911625ms | Sys: 310359ms
RSS: 1.64GB | Peak: 1.76GB | Commit: 2.87GB | Faults: 12324193 | Machine: 0.14TB

panic(main thread): Segmentation fault at address 0xFFFFFFFFFFFFFFFF
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

Bun crash report link: https://bun.report/1.3.10/e_11423d3cmgkgEuhogCgn92Wk+n1tB4kz/pC41j7pC6kh7pConrqXo8r0U23wN+o5gUmznlOqn4kOwkkqvDCYKERNEL32.DLLut0LCSntdll.dll4gijBA2DD

Reproduction Context

The crash occurred during a multi-agent orchestration session:

1. A master-orchestrator (Opus) spawned and coordinated work across multiple phases
2. 3 developer subagents were running in parallel (Wave 1 of an enterprise bundle generation pipeline)
3. Each subagent triggered 12-14 PreToolUse/PostToolUse hooks per tool call via settings.json hook entries (each hook spawns a child process)
4. The session had ~2075 messages at time of crash, context was at 6% remaining
5. The crash happened mid-write — the debug log ends abruptly during a PostToolUse hook match for a Write tool call

The session was active for approximately 1 hour of actual work (the 49843559ms elapsed includes idle time where the process was backgrounded).

Relationship to #21875

This matches Family 2 from the comprehensive root cause analysis in #21875:

• Crash address: 0xFFFFFFFFFFFFFFFF — NaN-boxed type tag for a freed/corrupted JSC value
• Mechanism: JSC garbage collector corruption during MarkedBlock sweep after abort_signal frees WatchpointSets
• Trigger pattern: Multiple concurrent child_process spawns (3 parallel subagents + hook processes)

The key difference: this is on Bun 1.3.10, not 1.3.5. The embedded Bun was updated but the GC race condition persists.

Notable Stats from This Crash

• spawn(3245) — 3,245 child process spawns in one session
• abort_signal(3128) — 3,128 abort signals
• fetch(1649) — 1,649 fetch calls

The high spawn count is expected given the hook architecture (2-6 hooks fire per tool call × hundreds of tool calls across subagents), but this volume appears to exacerbate the GC race.

Debug Log

Full debug log available at: C:\Users\oimir\.claude\debug\4d156d4c-e9ed-4a1b-8bda-51b39ff7fbb4.txt (3.5MB, 19,327 lines). Can provide on request.

Expected Behavior

Claude Code should not segfault during normal multi-subagent orchestration on Windows.

Requested Action

Update the embedded Bun runtime to a version that resolves the JSC GC use-after-free race condition, or implement a mitigation in Claude Code's child_process spawning path to reduce concurrent GC pressure.