[BUG] Segfault at startup on Linux from 2.1.251 onward (bundled Bun 1.4.1); 2.1.243 with Bun 1.4.0 works

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Every Claude Code version that bundles Bun 1.4.1 segfaults about 25ms after launch, before the
TUI appears. The last version bundling Bun 1.4.0 (2.1.243) works normally on the same machine.

This also blocks Fable 5.1, which requires 2.1.251 or newer (API returns
claude_code_version_too_old: "version 2.1.251 or newer is required"). So on this machine there is
no version that both starts and supports the model.

Bundled Bun version extracted with:
strings .../bin/claude.exe | grep -oE 'Bun v1\.[0-9]+\.[0-9]+' | head -1

Claude Code | Bundled Bun | Result
2.1.243 | 1.4.0 | works
2.1.251 | 1.4.1 (392624bed) | segfault
2.1.258 | 1.4.1 (e6b1ba42d) | segfault

claude --version succeeds on 2.1.251 and exits 0. Every path that actually starts the agent
crashes, including with stdin redirected or piped:

claude -> segfault
claude -p "hi" -> segfault
claude -p "hi" < /dev/null -> segfault
echo "" | claude -p "hi" -> segfault

What I ruled out:

• Config: removing ~/.claude.json does not help.
• Working directory: reproduces in several project dirs and in /tmp.
• Userspace library injection: /etc/ld.so.preload does not exist on this machine.
• Resource limits: ulimit -s is 8192 (not unlimited), virtual memory unlimited.
• Bun 1.4.1 itself: a separately installed Bun 1.4.1 works fine on this machine, including its

single-file executable mechanism:

curl -fsSL https://bun.sh/install | bash -s "bun-v1.4.1"
~/.bun/bin/bun --version # 1.4.1
~/.bun/bin/bun -e 'console.log(1+1)' # 2
echo 'console.log("ok")' > t.js
~/.bun/bin/bun build --compile t.js --outfile t-bin
./t-bin # ok

Same Bun version, same compile mechanism, runs correctly. The crash is specific to the
Claude Code bundle.

Partially tested: env -i HOME=$HOME PATH=$PATH TERM=xterm-256color claude --version and
setarch -R claude --version both succeed, but I only exercised the --version path with those,
so they do not rule out env or ASLR effects on the crashing path.

What Should Happen?

Expected: 2.1.251 and later start normally, as 2.1.243 does on the same machine.

Actual: SIGSEGV at address 0x0 roughly 25ms after launch, core dumped, no TUI.

Error Messages/Logs

============================================================
Bun v1.4.1 (392624bed) Linux x64
Linux Kernel v6.8.0 | glibc v2.35
CPU: sse42 popcnt avx avx2
Args: "claude"
Features: jsc standalone_executable claude_code
Builtins: "bun:main" "node:async_hooks" "node:crypto" "node:fs" "node:fs/promises" "node:os" "node:path" "node:process"
Elapsed: 26ms | User: 17ms | Sys: 9ms
RSS: 56.25 MB | Peak: 55.57 MB | Commit: 59.12 MB | Faults: 0 | Machine: 0.13 TB
panic: Segmentation fault at address 0x0

Bun crash reports:
  2.1.251: https://bun.report/1.4.1/l_1392624bkggggIggggCwhqGy0tG0mq+mCsuv8mCykk+mCwgpGgotGkollBA2AA
  2.1.258: https://bun.report/1.4.1/l_1e6b1ba4kggggQggggCwhqGy0tG0nugnCsvz+mCylognCwgpGgotGkollBA2AA

Features lists only "jsc standalone_executable claude_code" -- no Bun.stdout, fetch or spawn --
so the process dies before touching stdout or the network.

strace, main thread only (the other PID in the full trace is Bun's crash-report thread doing
process_vm_readv after the fact):

mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7bf557f0f000
madvise(0x7bf557f0f000, 4096, 0xffffffff /* MADV_??? */) = -1 EINVAL
madvise(0x7bf557f0f000, 4096, MADV_WIPEONFORK) = 0
getrandom(..., 48, 0) = 48
mprotect(0x7bf400b90000, 524288, PROT_READ|PROT_WRITE) = 0
rt_sigaction(SIGRT_1, {sa_handler=0x7bf557c91830, ..., SA_ONSTACK|SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
mmap(NULL, 528384, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7bf553637000
mprotect(0x7bf553638000, 524288, PROT_READ|PROT_WRITE) = 0
clone3({flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|...,
        stack=0x7bf553637000, stack_size=0x7a680, tls=0x7bf5536b7640}
       => {parent_tid=[2126093]}, 88) = 2126093
sched_getaffinity(2126093, 32, [0..63]) = 8
fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x4), ...}) = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x4), ...}) = 0
+++ killed by SIGSEGV (core dumped) +++

The crash lands shortly after a worker thread is spawned via clone3. The TCGETS/fstat calls on
fd 0 are the last visible syscalls but are not the trigger -- the crash also occurs with stdin
redirected from /dev/null.

Steps to Reproduce

1. npm install -g @anthropic-ai/claude-code@2.1.251
2. claude --version -> prints 2.1.251, exits 0
3. claude -> SIGSEGV, core dumped

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.243

Claude Code Version

2.1.251 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

Install method: npm global via nvm (Node v22.23.2).
claude doctor reports: Running: npm-global (2.1.243), Config install method: global,
Platform: linux-x64.
Binary path: ~/.nvm/versions/node/v22.23.2/lib/node_modules/@anthropic-ai/claude-code/bin/claude.exe

Hardware: 64 logical CPUs, ~128 GB RAM, AVX2 present (non-baseline Bun build).

One possibly relevant detail: sched_getaffinity returns an 8-byte mask on this 64-CPU machine,
right before the crash.

Since the regression tracks the bundled Bun version (1.4.0 -> 1.4.1) exactly, the root cause may
be upstream in Bun rather than in Claude Code itself. Happy to run any further diagnostics.