Claude Code 2.1.113+ crashes on startup (SIGILL in bundled Bun 1.3.14) on Intel Emerald Rapids / Ubuntu 24.04

Summary

Every Claude Code release from 2.1.113 onward (the switch from a Node-based cli.js to a Bun single-executable bin/claude.exe) crashes on startup with a SIGILL inside the bundled Bun v1.3.14 runtime. The crash fires in ~4ms, before any Claude Code code runs — --version and --help both die.

Reverting to 2.1.112 (the last Node-based release) works perfectly on the same machine.

Reproduction

curl -fsSL https://claude.ai/install.sh | bash
# OR
npm install -g @anthropic-ai/claude-code
claude --version

Output:

============================================================
Bun v1.3.14 (521eedd6) Linux x64 (baseline)
Linux Kernel v6.8.0 | glibc v2.39
CPU: sse42 popcnt avx avx2 avx512
Args: "claude" "--version"
Features: jsc standalone_executable claude_code
Elapsed: 4ms | User: 0ms | Sys: 5ms
RSS: 24.44MB | Peak: 12.58MB | Commit: 24.44MB | Faults: 0

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

https://bun.report/1.3.14/B_1521eeddkggggEggggC+ypRq9yxpC09vypCovs4wCy5/qpC6z0qpCy8wK0oxK6iyqpCA2AA

Illegal instruction (core dumped)

Environment

| Field | Value |
|---|---|
| Claude Code | 2.1.113 through 2.1.161 (all reproduce) |
| Bundled Bun | v1.3.14 (521eedd6) Linux x64 baseline |
| OS | Ubuntu 24.04.1 LTS (Noble) |
| Kernel | 6.8.0-1044-oracle (Oracle-flavored, OCI-backed K8s host) |
| glibc | 2.39-0ubuntu8.4 |
| CPU | Intel Xeon Platinum 8592+ (Emerald Rapids, 2× 64-core / 256 thread) |
| CPU flags | full avx, avx2, avx512f/dq/bw/vl/vnni/bf16/fp16, avx_vnni, amx_tile, amx_int8, amx_bf16 |
| Container | Kubernetes pod (RunAI), seccomp mode 2, 1 filter installed |

Notably, the CPU has all baseline Bun requirements (and far more) — this isn't a missing-instruction issue at the hardware level.

Diagnostics already performed

• strace shows the crash happens right after JSC sets up its 128 GiB JSGigacage anonymous mmap and a 2 GB PROT_NONE mprotect. The final syscall before SIGILL is the gigacage mprotect. No -EPERM or -EACCES from seccomp in the trace.
• The SIGILL fires at address 0x2b05212 inside the binary's text segment, signaled as ILL_ILLOPN (illegal opcode), then Bun's handler triggers a secondary SIGSEGV at 0x0 that produces the panic line.
• Env-var workarounds that do not help (crash happens before they're consulted):

BUN_JSC_useJIT=0, BUN_DISABLE_JIT=1, BUN_JSC_useDFGJIT=0, BUN_JSC_useConcurrentJIT=0, JSC_useJIT=0, JSC_useGigacage=0 (rejected as "invalid option"), JSC_useWebAssembly=0, WEBKIT_JSC_useJIT=0.

• npm package and the curl-installed standalone binary both reproduce identically (same bundled binary).
• The crash is fully deterministic — happens on every invocation including --version.

Workaround

npm install -g @anthropic-ai/claude-code@2.1.112
# also disable the auto-updater so it doesn't roll forward into the broken Bun build:
echo '{"autoUpdaterStatus":"disabled"}' > ~/.claude/settings.json
export DISABLE_AUTOUPDATER=1

Bun crash report URL

For forwarding to the Bun team if helpful:

https://bun.report/1.3.14/B_1521eeddkggggEggggC+ypRq9yxpC09vypCovs4wCy5/qpC6z0qpCy8wK0oxK6iyqpCA2AA

Asks

1. Consider bumping the bundled Bun version (or building Bun with a different baseline target) in the next Claude Code release — there are multiple Bun 1.3.x reports of startup SIGILL on Sapphire / Emerald Rapids Xeon hosts.
2. In the meantime, would it be possible to keep publishing a Node-based fallback (a la cli-wrapper.cjs actually running the JS bundle in-process) for environments where the Bun SEA crashes? The wrapper currently only re-spawns the native binary, which provides no escape hatch.
3. Document the 2.1.112 rollback in a known-issues note so other users on Emerald Rapids / Sapphire Rapids K8s hosts can find the workaround.