Skip to content

[BUG] N-API addon lifecycle crash — same segfault on both Bun and Node.js runtimes #27356

Closed as not planned

Description

@jw409

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):

  1. Main thread calls napi_remove_async_cleanup_hook — begins freeing async resources
  2. Worker threads are simultaneously inside napi_unref_threadsafe_function — still using those resources
  3. 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:

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

Claude Code Version

2.1.50

Platform

Anthropic API

Operating System

Windows + WSL2 (cross-platform confirmed per #21875)

Activity

  1. jw408 commented on Feb 21, 2026

    @jw408

    endorsed

  2. balandari commented on Feb 21, 2026

    @balandari

    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_hook while workers hold references), both sides need fixing.

    Your framing that the shared 0xFFFFFFFFFFFFFFFF sentinel 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.

  3. github-actions commented on Mar 21, 2026

    @github-actions

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.

  4. github-actions commented on Mar 30, 2026

    @github-actions

    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.

  5. locked as resolved and limited conversation to collaborators on Mar 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    staleIssue is inactive

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions