Startup SIGILL in 2.1.241 (Bun v1.4.0 fdb5e06cc) — 71% of launches; 2.1.243 (Bun 19bc277a0) is clean in 17/17

Summary

Claude Code 2.1.241 crashes on startup with a Bun SIGILL panic at a fixed
address, roughly 950 ms in, before any prompt is processed. Claude Code
2.1.243 does not — and the difference lines up with the bundled Bun build,
not the version string:

| Claude Code | bundled Bun | startup crashes |
|---|---|---|
| 2.1.241 | Bun v1.4.0 (fdb5e06cc) | 5 of 7 launches (71%) |
| 2.1.243 | Bun v1.4.0 (19bc277a0) | 0 of 17 launches |

Both report v1.4.0; the commit hashes differ. So whatever changed between
fdb5e06cc and 19bc277a0 appears to fix (or move) this.

I'm filing here rather than on oven-sh/bun because the actionable fact is a
packaging one — which Bun build ships in which Claude Code release — and
because I cannot reproduce it against a standalone Bun.

The crash

============================================================
Bun v1.4.0 (fdb5e06cc) Linux x64
Linux Kernel v7.0.0 | glibc v2.39
CPU: sse42 popcnt avx avx2 avx512
Args: ".../claude" "--model" "claude-opus-5" "--permission-mode" "bypassPermissions" "--append-system-prompt" "You are ..."
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) fetch(2) jsc spawn(4) standalone_executable yaml_parse(34) claude_code
Elapsed: 947ms | User: 877ms | Sys: 206ms
RSS: 0.26 GB | Peak: 0.32 GB | Commit: 0.35 GB | Faults: 54

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

Redacted crash report:
https://bun.report/1.4.0/l_1fdb5e06mgggkIugogC8p11lFk7voBgwzylFm4mhxEqy5hhF8pv9lF00v3lFkuugmF+n82lF+ts+lF_2+8z7D2/j07D2/j07D_gp7z7Dgp7z7D_gp7z7D_A3A+p11lF

The crash address 0x52D6A9F and the bun.report hash are byte-identical
across every occurrence, so this is one code path, not several. Elapsed is
consistently 920–950 ms.

How it was measured

Claude Code is being launched repeatedly as a subprocess by a multi-agent
harness, which gave a clean sample of 24 launches with timestamps. A launch
that died inside 5 s with signal=4 is counted as a crash:

version   launches  crashes   rate
2.1.241          7        5     71%
2.1.243         17        0      0%

Timeline:

~15:53–17:13   on 2.1.241     3 crashes
 19:03         2.1.243 installed
 19:21–22:57   on 2.1.243     17 launches, 0 crashes
 23:00         reverted to 2.1.241  (see below)
 23:19         2 crashes, identical signature

Seventeen consecutive clean launches on 2.1.243 against 5 failures in 7 on
2.1.241.

One inference stated plainly: the 23:00 revert is recorded on disk; that
2.1.243 became active when installed at 19:03 is inferred from installer
behaviour, not observed. Everything else above is measured.

An odd secondary observation

~/.claude/.last-update-result.json recorded a downgrade, marked success:

{"timestamp":"2026-08-25T04:00:25.376Z","path":"native","outcome":"success",
 "status":"success","version_from":"2.1.243","version_to":"2.1.241","error_code":null}

~/.local/bin/claude was repointed from 2.1.243 to 2.1.241 at that moment, and
the crashes resumed 19 minutes later. I don't know what triggered the rollback —
nothing else on disk records it. If the updater can roll back to an older
build, that would explain how a user lands on a crashing one after having been
fine.

Environment

• CPU: Intel Xeon Gold 6136 (Skylake-SP). Has `avx512f avx512bw avx512cd

avx512dq avx512vl; does **not** have the newer subsets (avx512_vnni,
avx512_vbmi, avx512_bf16). Bun's banner prints a flat avx512`.

• OS: Ubuntu 24.04.4 LTS, kernel 7.0.0-30-generic, x86_64, glibc 2.39
• Install: native installer, ~/.local/share/claude/versions/
• Invocation: non-interactive spawn into a PTY, with --model,

--permission-mode bypassPermissions, --append-system-prompt (~10 KB) and
--settings <file> (6 MCP servers, 9 hook types, a statusLine command)

What I could not reproduce

Five targeted attempts on 2.1.241 all ran clean: a 10 KB
--append-system-prompt alone; interactive under script; under a
systemd --user environment; with the real --settings payload; and finally
spawned through the harness's own node-pty under Electron in the same working
directory. So it is not determined by prompt size, flag shape, environment,
settings payload, CWD, or the PTY layer.

It does correlate with concurrent launches: in the 23:19 batch, three agents
started within one second and two of the three crashed. But that isn't
sufficient either — an earlier batch of three simultaneous launches on 2.1.243
all survived.

Given the fixed crash address and a ~950 ms Elapsed on every occurrence, a
JIT/codegen path during startup seems more likely than anything input-dependent,
but I have no symbols to confirm that.

Ask

1. Is the Bun bump between fdb5e06cc and 19bc277a0 known to fix a startup

SIGILL? If so, 2.1.241 is worth yanking or superseding.

1. Can the native updater roll back a version, and under what conditions?

That is how this machine ended up on the crashing build after hours of
stability.

Happy to run anything diagnostic — the environment reproduces it at ~71% on
demand simply by pointing the symlink back at 2.1.241.