[BUG] SIGILL (`cntb`, SVE) on linux-arm64 in Android AVF guest

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?

this was already reported as #55519, but the report has been auto-closed

Claude Code 2.1.296 (linux-arm64) cannot start inside the Android "Linux Terminal" (an Android Virtualization Framework / pKVM guest running Debian 13). Both the installer step (claude-2.1.296-linux-arm64 install) and a plain --version print only the Bun crash banner and then hang forever:

============================================================
Bun v1.4.3 (eecfd55de) Linux arm64

Root cause (verified with strace + objdump):

1. Early in startup, the process receives SIGILL (ILL_ILLOPC) at 0x2381d08. The instruction there is cntb x8, an SVE instruction:

 2381d00:  a9bf7bfd  stp   x29, x30, [sp, #-16]!
 2381d04:  910003fd  mov   x29, sp
 2381d08:  0420e3e8  cntb  x8            <-- SIGILL
 2381d0c:  f100411f  cmp   x8, #0x10
 2381d10:  52a00109  mov   w9, #0x80000
 2381d14:  1a9f17ea  cset  w10, eq
 2381d18:  6a405d5f  tst   w10, w0, lsr #23
 2381d1c:  52a0008a  mov   w10, #0x40000

1. In this guest, SVE is disabled for userspace, but the kernel still advertises SVE2 and the SVE extensions:

$ LD_SHOW_AUXV=1 /bin/true | grep HWCAP
AT_HWCAP:             efbfffff      # bit 22 (HWCAP_SVE) NOT set
AT_HWCAP2:            0x801af3ff    # bit 1 (HWCAP2_SVE2) set, plus SVEAES, SVEPMULL, SVEBITPERM, SVESHA3, SVESM4, SVEI8MM

/proc/cpuinfo Features accordingly contain sve2 sveaes svepmull svebitperm svesha3 svesm4 svei8mm svebf16 but not sve.

The CPU-feature detection in the bundled native code apparently trusts SVE2/ID-register information instead of HWCAP_SVE, executes cntb, and is killed.

1. Bun's crash handler then starts, prints the banner, reads /proc/self/maps and THP settings, and deadlocks in futex(0x54ff700, FUTEX_WAIT, 65792, NULL). As a result, the user never sees an error, only a hang. This makes the problem look like "installation hangs" rather than a crash.

What Should Happen?

• SVE code paths should only be used when HWCAP_SVE (AT_HWCAP bit 22) is set, falling back to NEON otherwise. SVE2 hwcaps alone should not be taken as proof that SVE instructions are usable.
• If the runtime does crash, the crash handler should not deadlock: it should print the report and exit.

Error Messages/Logs

Relevant strace excerpt (`strace -f -o /tmp/cc.trace claude-2.1.296-linux-arm64 --version`):


136: 2432  --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPC, si_addr=0x2381d08} ---
...
     2432  futex(0x54ff700, FUTEX_WAIT, 65792, NULL) = ? ERESTARTSYS
157: 2432  --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, ...} ---   # from `timeout`

Steps to Reproduce

1. On an Android device with the built-in Linux Terminal (AVF) enabled, open the Debian terminal.
2. Run curl -fsSL https://claude.ai/install.sh | bash.
3. The installer stops after Setting up Claude Code... with only the Bun banner shown.
4. Alternatively, run the downloaded binary directly: ~/.claude/downloads/claude-2.1.296-linux-arm64 --version. This also hangs.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.296

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Xterm

Additional Information

Operating System

Debian 13 (trixie), arm64, inside the Android Linux Terminal (AVF/pKVM guest)

$ uname -a
Linux localhost 6.1.0-34-avf-arm64 #1 SMP Debian 6.1.135-1 (2025-04-25) aarch64 GNU/Linux

• Page size: 4096. User VA: 48-bit (stack at ffffc41a5000). RAM: 3.8 GiB + 5.9 GiB swap. ulimit -v unlimited. vm.overcommit_memory = 0. Address space and memory are not the cause.
• Full CPU features (/proc/cpuinfo):

fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh bti ecv afp wfxt

• Chromium (V8) runs fine in the same environment, so the VM is generally functional. Only this SVE path is affected.
• The inconsistent hwcaps (SVE2 without SVE) are arguably also a kernel/AVF issue, but any software gating SVE on HWCAP_SVE handles this environment correctly.
• Related: no official Android build exists (#50270), but this environment is a regular glibc Debian VM, not Termux.