Repository navigation
Description
Preflight Checklist
- I have searched existing issues and this hasn't been reported yet
- This is a single bug report
- I am using the latest version of Claude Code
What's Wrong?
Claude Code appears to crash through the same N-API code path on both Bun and Node.js runtimes. This suggests the root cause may be in Claude Code's native addon lifecycle rather than in Bun specifically.
Crash signatures across runtimes (from public issue data):
| Runtime | Version | Fault Address | Crash Function | Source |
|---|---|---|---|---|
| Bun | v1.3.5 | 0xFFFFFFFFFFFFFFFF |
napi_close_callback_scope |
#21875 |
| Bun | v1.3.10 | 0xFFFFFFFFFFFFFFFF |
uv__process_pipe_write_req |
#27320 |
| Node.js | v22.22.0 | 0xFFFFFFFFFFFFFFFF |
napi_close_callback_scope via V8 |
#21875 (Feb 14 comment) |
The shared fault sentinel (0xFFFFFFFFFFFFFFFF) across two different JS engines (JSC and V8) is notable. If confirmed, this would rule out a runtime-specific bug and point to Claude Code's native .node addon.
Hypothesis (not independently verified)
Based on dump analysis published in #21875 (27 full memory dumps analyzed via WinDbg by @balandari):
- Main thread calls
napi_remove_async_cleanup_hook— begins freeing async resources - Worker threads are simultaneously inside
napi_unref_threadsafe_function— still using those resources - Cleanup frees/corrupts a function pointer while workers hold references ->
ACCESS_VIOLATION
We have not independently reproduced this. This hypothesis is based on cross-referencing public crash data across issues. The dump analysis and cross-runtime findings were produced by @balandari in #21875.
Why this matters now
#21875 requested a Bun version bump as the fix. That happened (v1.3.5 -> v1.3.10). New crash reports on v1.3.10 with identical signatures suggest the bump was insufficient:
- [BUG] Segmentation fault in Bun v1.3.10 (Windows) during long sessions — pipe write crash #27320:
0xFFFFFFFFFFFFFFFF(same sentinel), Bun v1.3.10, 3.5 min session - [BUG] Bun segfault crash after ~2h session on Windows x64 (Bun v1.3.10) #26984:
0x4B750B20520(heap address), Bun v1.3.10, 2h session
If the root cause is in the addon's cleanup ordering rather than the runtime, version bumps alone won't resolve this.
What Should Happen?
Investigation into whether the native addon's threadsafe_function cleanup is properly synchronized with worker thread lifecycle.
Related Issues
- Repeated Bun v1.3.5 segfaults -- 78 crashes, root cause identified (Windows + WSL) #21875 — 78 crashes, 27 dumps, full root cause analysis (originally framed as Bun-specific)
- [BUG] Segmentation fault in Bun v1.3.10 (Windows) during long sessions — pipe write crash #27320 — Bun v1.3.10 still crashing, same signature
- [BUG] Bun segfault crash after ~2h session on Windows x64 (Bun v1.3.10) #26984 — Bun v1.3.10, 2h session crash
- [BUG] SyntaxError: Too many arguments (65535 limit) on restart after session crash - Node.js v22.22.0 #24874 — Node.js 65535 args limit crash after session crash at ~80% context
- SIGABRT crash: native .node addon deleted from /tmp during runtime (v2.1.42) #26057 — Native .node addon deleted from /tmp
Claude Code Version
2.1.50
Platform
Anthropic API
Operating System
Windows + WSL2 (cross-platform confirmed per #21875)
Activity
jw408 commentedon Feb 21, 2026
endorsed
balandari commentedon Feb 21, 2026
Good write-up. A few pieces that may be useful for your cross-runtime framing:
The Bun side of this was filed separately as oven-sh/bun#27003 with full ProcDump analysis — 80+ crashes classified into four distinct families, all converging on
napi_close_callback_scope. Jarred Sumner authored PR oven-sh/bun#27026 to fix the use-after-free on Bun's end. The branch name (claude/fix-napi-callback-scope-uaf-and-timer-leaks) confirms it targets the exact path you're referencing here.That fix merged but hasn't shipped in a Claude Code update yet. The fact that #27320 still crashes on Bun v1.3.10 is consistent with your addon-side hypothesis — the Bun fix addresses Bun's handling of the cleanup, but if Claude Code's addon is also initiating the race (calling
napi_remove_async_cleanup_hookwhile workers hold references), both sides need fixing.Your framing that the shared
0xFFFFFFFFFFFFFFFFsentinel across JSC and V8 points to the addon rather than the runtime is the right thread to pull. The dump analysis in #21875 supports that — the crash families show the same cleanup-ordering pattern regardless of which engine is underneath.Note
This comment was written by Claude (Opus 4.6) on behalf of @balandari as part of our AI-assisted development workflow.
github-actions commentedon Mar 21, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon Mar 30, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.