[BUG] Bun 1.4.0 segfault at address 0x10 on main thread (JSC JSStringJoiner/JSArray::fastToString frames) after 21.8 h session with 8 live subagents — CLI 2.1.235, Windows 11 26200

Preflight Checklist

• [x] I have searched existing issues — closest matches are #77579, #75538, #87616, #86657, #73196 (all Bun 1.4.0 segfaults on Windows x64). This trace differs on three axes, so I am filing separately per the one-bug-per-report guidance: the fault address is a clean near-null 0x10 (not the 0x...00000050 poisoned-high-bits shape of #77579 / #75538), the panic is on the main thread (not #87616's background thread with KERNEL32/ntdll-only frames), and the decoded trace lands in JSC's string-join path, not the GC mark phase. See Related for how I think it connects.
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.235)

What's Wrong?

An interactive CLI session died with a Bun runtime segfault after 21 h 48 m of process uptime (Elapsed: 78465504ms), with 8 concurrent subagents live at the moment of death:

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

Not memory pressure. RSS 0.19 GB, peak 0.89 GB, commit 0.84 GB on a 25.5 GB machine — ~3.5 % of RAM at peak. Only Bun's own panic handler fired; no Windows Error Reporting entry.

Symbolized trace. The bun.report link below resolves and decodes cleanly, which independently validates the URL transcription. Frames as returned, verbatim:

Bun v1.4.0 (939d432) on windows x86_64 [StandaloneExecutable]
Segmentation fault at address 0x00000010

- ?getDisplayNames@ICUService@icu_78@@...
- ?copyData@DateFormatSymbols@icu_78@@...
- ?copyData@DateFormatSymbols@icu_78@@...
- sha1-x86_64-win.asm:4682  sha1_block_data_order_avx2
- WebAssemblyMemoryPrototype.cpp:82  JSC::webAssemblyMemoryProtoFuncGrow
- VM.cpp:1088  JSC::VM::hasExceptionsAfterHandlingTraps
- JSStringJoiner.h:152  JSC::JSStringJoiner::appendWithoutSideEffects
- JSStringJoiner.h:196  JSC::JSStringJoiner::append
- JSArray.cpp:1099  JSC::JSArray::fastToString
- *7 unknown/js code*
- RefPtr.h:101  WTF::RefPtr<WTF::MetaAllocatorHandle,...>::RefPtr
- ThunkGenerator.h:36  JSC::MacroAssemblerCodeRef<357>::MacroAssemblerCodeRef
- NeverDestroyed.h:138  WTF::LazyNeverDestroyed<JSC::MacroAssemblerCodeRef<357>,WTF::AnyThreadsAccessTraits>::constructWithoutAccessCheck
- NeverDestroyed.h:128  WTF::LazyNeverDestroyed<...>::construct
- LLIntThunks.cpp:779  JSC::LLInt::returnLocationThunk::<lambda_88>::operator()
- type_traits:1670  std::invoke
- xcall_once.h:103  std::call_once<lambda at LLIntThunks.cpp:779:5>

Reading of the trace. Most of that list is a mis-walked stack: the ICU getDisplayNames / DateFormatSymbols::copyData frames, the BoringSSL sha1_block_data_order_avx2 frame, and the webAssemblyMemoryProtoFuncGrow frame have nothing to do with each other or with anything this session did, and the tail (LLIntThunks / call_once / LazyNeverDestroyed) is one-time JIT thunk initialization that cannot plausibly be live 21 hours in. The same unwinder unreliability is visible in #87616, whose trace resolved to KERNEL32/ntdll only. The one internally consistent run is:

JSC::JSArray::fastToString                             (JSArray.cpp:1099)
  -> JSC::JSStringJoiner::append                       (JSStringJoiner.h:196)
       -> JSC::JSStringJoiner::appendWithoutSideEffects (JSStringJoiner.h:152)

That is the main thread turning an array into a string (Array.prototype.join, or an implicit toString) and reading off a null base at offset 0x10.

I want to be careful about what that does and does not establish. It says where the process died, not what broke. #77579 makes a good argument that this whole Windows family is one JSC heap corruption surfacing wherever GC or JS next touches the poisoned cell — under that reading the string joiner here is the next toucher rather than the culprit, and 0x10 versus 0x...50 is just a different field offset off a different dead base. A single crash cannot separate those two readings, so I am reporting the observation, not the conclusion.

What Should Happen?

A long-lived session with concurrent subagents should not be able to take the host process down. Failing that, a JS-level error is far cheaper than a native panic: this segfault killed 8 in-flight agents with no completion record and dropped the whole session mid-task.

Error Messages/Logs

============================================================
Bun v1.4.0 (939d4325b) Windows x64
Windows v10.26200th-001
CPU: sse42 avx avx2
Args: "C:\Users\<user>\.local\bin\claude.exe" "--dangerously-skip-permissions"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) WebSocket(2) abort_signal(60) fetch(122) jsc spawn(565) standalone_executable yaml_parse(3795) claude_code
Builtins: "bun:ffi" "bun:main" "node:tty" "node:url" "node:util" "node:vm" "node:worker_threads" "node:zlib" "ws"
Elapsed: 78465504ms | User: 480796ms | Sys: 286250ms
RSS: 0.19 GB | Peak: 0.89 GB | Commit: 0.84 GB | Faults: 1961781 | Machine: 25.50 GB

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

Transcribed from the terminal. The Builtins: line is truncated to what was on screen, and the CPU: line was partly overlapped by the statusline — sse42 avx avx2 is the legible part.

Crash report link, which decodes to the trace above:

https://bun.report/1.4.0/w_1939d432mgggkI+hogCgns7Fw49sEgn+sE6pysDgv99+Cs+si7B_______os567C_____A2AgB

Two counters stand out against the other reports in this family: yaml_parse(3795) and spawn(565), both an order of magnitude above what #87616 recorded (yaml_parse(85), spawn(60)) and #77579 (yaml_parse(62), spawn(72)). Consistent with heavy skill/agent frontmatter loading and tool-call churn over a very long session.

Steps to Reproduce

No deterministic repro — it happened once, during ordinary use. The shape of the session that produced it:

1. Native-installer claude.exe in Windows Terminal, --dangerously-skip-permissions, no IDE extension.
2. Model Opus 5 with the 1M context window; statusline read ctx:81% (190k/1.0M) at death.
3. The same session kept alive ~21.8 h across many tasks in one git repo.
4. Heavy Agent tool use throughout — the session's transcript directory accumulated 26 subagent transcripts, and 8 agents were live when the panic hit.
5. The crash arrived with no user action to point at.

Environment

| | |
|---|---|
| Claude Code | 2.1.235, auto-update channel: latest |
| Install | native installer, C:\Users\<user>\.local\bin\claude.exe (not npm) |
| Bundled runtime | Bun v1.4.0 (939d4325b), windows x86_64 [StandaloneExecutable] — same build as #87616 |
| OS | Windows 11 Home, build 10.0.26200 |
| CPU | sse42 avx avx2 (note: this build is not the baseline variant seen in #77579 / #73196) |
| RAM | 25.5 GB |
| Host | Windows Terminal, plain claude |
| MCP | several stdio servers connected |

Impact and recovery

The process died with the session's work in flight, orphaning 8 running agents. The transcript itself survived — claude --resume from the same directory picked the session back up, so nothing was lost beyond the in-flight agent results. Worth stating only because it means the failure is recoverable rather than silent data loss.

Related

Same Windows / Bun 1.4.0 segfault family:

• #77579 — main thread, JSC GC use-after-free at 0x296_00000050, fully symbolized, reproduces at idle load. Argues the family is one JSC heap corruption; this report is a datapoint for that argument from the opposite end of the load spectrum.
• #75538 — same address family under ~25 concurrent subagents. Closest to this report on session shape (subagent fan-out), different fault address.
• #87616 — 0x54, background thread, same Bun build (939d432), same near-null offset family.
• #86657 — Windows 11 build 26200, ~3.5 h session, claude-vscode host.
• #73196 — Windows, Bun 1.4.0, but crashes on every command at startup; likely unrelated.

Upstream, on Bun's tracker: oven-sh/bun#26843 is the same 0x10 address in the Claude Code standalone executable, on macOS arm64 with Bun 1.3.9-canary — the only other 0x10 report I found tied to this app. Closed historical 0x10 panics: oven-sh/bun#22557, oven-sh/bun#14800. Note that bun.report states the embedded Bun 1.4.0 is ahead of Bun's latest public release (1.3.14), and directs crash reports from embedded builds to the app developer, which is why this is filed here.

Happy to run an instrumented build, keep a session under a debugger, or provide more of the transcript if any of it would help.