[BUG] Claude Code fails with SIGILL on pre-SSE4.1 CPUs; request for a lower baseline build

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?

The current native binary requires x86-64-v3. On an AMD Phenom II X4 (K10)
it dies at startup with SIGILL. Version 2.1.14 works, since it shipped a JS
entry point rather than a compiled binary. This report adds a data point below
the floor in existing reports: every prior case I found is a machine with
SSE4.2 that lacks AVX/AVX2. K10 lacks SSE4.1, so it fails even a baseline v2
(x86-64-v2) build.

What Should Happen?

I would like to be able to select a lower baseline build at install

Error Messages/Logs

$ gdb -batch -ex run -ex 'x/i $pc' -ex 'info registers rip' --args bin/claude --version

Thread 1 "claude" received signal SIGILL, Illegal instruction. 
0x000000000305c839 in ?? () 
=> 0x305c839:   pinsrq $0x0,%rsi,%xmm1 
rip            0x305c839           0x305c839

Steps to Reproduce

$ npm install -g @anthropic-ai/claude-code@latest
$ claude

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

v2.1.14

Claude Code Version

2.1.218

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

Environment

Claude Code: 2.1.218 (crashes); 2.1.14 (works)
CPU: AMD Phenom II X4 (K10, 2009). SSE4a, no SSE4.1/4.2, no AVX
OS: Fedora 42, x86_64
Install: npm install -g @anthropic-ai/claude-code

Crash

Thread 1 "claude" received signal SIGILL, Illegal instruction.
0x000000000305c839 in ?? ()
=> 0x305c839: pinsrq $0x0,%rsi,%xmm1
rip 0x305c839 0x305c839

pinsrq is SSE4.1 (Intel 2007; AMD did not adopt it until Bulldozer, 2011).
K10 has SSE4a, which shares nothing with Intel's SSE4.1/4.2.

Instruction Counts

Against the 2.1.218 linux-x64 binary:

$ objdump -d claude | grep -cE 'pinsr|pextr|pcmpistr|ptest|blend|popcnt'
17105
$ objdump -d claude | grep -cE 'vpermd|vpbroadcast|vgather|vpsllvd'
1543

Both SSE4.x and AVX2 are pervasive, so this is the codegen baseline rather
than a few stray call sites. Effective floor: Haswell (2013) on Intel, Zen
(2017) on AMD.

Packaging

optionalDependencies covers OS, arch, and libc, but not microarchitecture:

$ npm view @anthropic-ai/claude-code optionalDependencies
{
'@anthropic-ai/claude-code-linux-x64': '2.1.218',
'@anthropic-ai/claude-code-linux-x64-musl': '2.1.218',
'@anthropic-ai/claude-code-darwin-x64': '2.1.218',
'@anthropic-ai/claude-code-linux-arm64': '2.1.218',
...
}

There is no baseline variant. Bun publishes one upstream, so the build-side
cost of adding a target and one optional dependency appears small.

Why local execution matters here

The usual answer to old hardware is to run Claude Code on a newer machine and
SSH in. That does not cover the case I care about. Kernel module conflicts,
driver faults, and hardware-specific bugs have to be investigated on the
machine exhibiting them: live dmesg, the actual failing hardware, and a
session that survives the module being unloaded and reloaded. Older hardware
is where these problems concentrate, and it remains fully supported by
current Fedora, Debian, and Ubuntu.

Request

In rough order of usefulness:

1. Publish a baseline (x86-64-v2) build as an additional optional

dependency. This would restore Bulldozer-era and later AMD, and
pre-Haswell Intel, though not K10.

1. Document the minimum CPU requirement, so users hitting SIGILL know to

pin an older version rather than debugging their install.

1. Detect unsupported CPUs at startup and print a clear message instead of

crashing. At present even "claude uninstall" fails with SIGILL, since
the runtime dies before argument parsing.

Claude Code is dominated by API round-trip latency rather than local CPU
work, so it is not obvious that the v3 vector paths buy measurable
wall-clock time in typical sessions. If that has been measured and v3 does
matter, that would be useful to state in the docs.

Happy to test a baseline build on pre-SSE4.1 hardware.

Related, but not identical, issues

#5864, #10408, #15030, #20019, #20611, #34481, #37065, #50466, #50904,
#62244 -- all AVX/AVX2 on SSE4.2-capable machines, several closed as
duplicate.