Segmentation fault at address 0x10 when running Claude Code standalone executable

[Light-code11]

What version of Bun is running?

1.3.9-canary.51+d5628db2

What platform is your computer?

Darwin 25.2.0 arm64 arm

What steps can reproduce the bug?

1. Run Claude Code via the Bun standalone executable (bun claude)
2. Use Claude Code in an extended session (~53 minutes)
3. Make changes that trigger a multi-file edit acceptance prompt (15 files, +162/-51 lines)
4. Bun crashes with a segfault at the edit acceptance prompt

I haven't been able to reproduce this consistently — it occurred once during normal usage.

What is the expected behavior?

Bun should not crash. The edit acceptance prompt should display normally and allow the user to accept or reject the proposed changes.

What do you see instead?

panic(main thread): Segmentation fault at address 0x10

oh no: Bun has crashed. This indicates a bug in Bun, not your code.

Crash report: https://bun.report/1.3.9/M_2d5628dbmgkgE+hogC_m/lnhCm79hhCu54khCu7o2gC2rm2gC+rp1gC2u11gC2to1gCmpj/gCm/qihCuzm2gC2or0gC+ukihCuv895Bm7325B____A2AgB

Additional information

Resource usage at crash:

• Elapsed: 3,202,865ms | User: 241,100ms | Sys: 46,948ms
• RSS: 0.54GB | Peak: 0.59GB | Machine: 17.18GB
• Page Faults: 2,553
• Commit: 0.02ZB (this value appears to be a separate reporting bug)

Active features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) WebSocket(155) abort_signal(195) fetch(710) jsc spawn(253) standalone_executable process_dlopen yaml_parse(5)

The process was running as a standalone executable. The crash happened during interactive terminal I/O (shift+tab cycling, edit acceptance UI).

[github-actions]

Found 3 possible duplicate issues:

1. bun crash while running claude code #21353
2. Crashed during Claude Code session #24033
3. Repeated crashes with JSON.stringify in Claude Code in Bun #23213

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[robobun]

Unfortunately, I was unable to reproduce this issue using Bun latest.

Summary

One-time, non-reproducible segfault on a canary build (1.3.9-canary.51+d5628db2) during interactive terminal I/O in a Bun standalone executable (Claude Code). The crash happened after ~53 minutes of heavy usage (155 WebSockets, 710 fetches, 253 spawned processes).

Investigation

Crash Report Analysis

• The crash report URL (bun.report) returned "Could not find debug info for this version of Bun" - no debug symbols available for this canary build, so the stack trace could not be decoded.
• Address 0x10 indicates a null pointer dereference with a 16-byte field offset, consistent with accessing a struct field on a freed/null object pointer.

Relevant Fix Already in Codebase

Commit e44246951d (2026-01-28) - "fix(spawn): prevent use-after-free in subprocess stdin cleanup":

When onProcessExit runs after the JSSink destructor has already freed the FileSink, the fromJS recovery path would read stale m_sinkPtr from the dead JSSink, accessing freed/reallocated memory. This could close file descriptors belonging to other subprocesses, corrupting their pipe communication.

The fix guards the fromJS recovery path with has_stdin_destructor_called flag in src/bun.js/api/bun/subprocess.zig:594:

- if (stdin == null) {
+ if (stdin == null and !this.flags.has_stdin_destructor_called) {

This fix matches the crash profile exactly:

• Null pointer + offset dereference: Accessing a field on freed memory that may have been zeroed
• 253 spawned processes: High subprocess count increases the race condition window
• Interactive terminal I/O: stdin handling is directly involved in the race condition
• Long-running session (53 min): Race conditions require specific GC timing

Additional Relevant Fixes in Current Codebase

• 89d2b1cd0b (2026-02-05) - fix(websocket): add missing incPendingActivityCount() in blob binaryType case - prevents premature GC of WebSocket objects
• 315e822866 (2026-02-03) - fix(bindgen): prevent use-after-free for optional string arguments
• 085e25d5d1 - fix: protect StringOrBuffer from GC in async operations

Why This Cannot Be Reproduced

1. The reporter explicitly states: "I haven't been able to reproduce this consistently — it occurred once during normal usage"
2. It's a race condition between GC finalizers and process exit callbacks
3. Requires specific timing under heavy load (253 processes, 155 WebSockets, 710 fetches)
4. Requires a standalone executable with interactive terminal I/O
5. The canary build commit (d5628db2) is not in this repository, so we cannot determine if the fix was included

Classification

This appears to be a one-time, non-reproducible crash on a canary build that is most likely addressed by the subprocess stdin use-after-free fix (e442469) and potentially other GC-related fixes already in the current codebase. The **** should upgrade to the latest stable release (1.3.9+) which includes all these fixes.

This is an automated comment. If you can provide additional reproduction steps or a minimal reproduction repository, please update this issue.