[BUG] auto-updater installed it without validation and broke `claude` ; (2.1.176 SIGILLs on launch on RHEL 7 / glibc 2.17)

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 auto-updater installed Claude Code 2.1.176 on a CentOS 7 / glibc 2.17 host and silently re-pointed ~/.local/bin/claude at the new binary. The new binary crashes immediately on every invocation with a Bun panic ("Bus error" → SIGILL, exit 132) — it can't even print its own --version.
The previous release, 2.1.170, runs cleanly on the exact same host.

Net result:
claude is unusable after the auto-update, and there is no automatic rollback. The CPU has AVX/AVX2/BMI1/BMI2 (Broadwell-class), so this isn't the well-known "no-AVX CPU" variant — it's a separate glibc/kernel ABI incompatibility in the Bun 1.3.14 runtime shipped with 2.1.176.

What Should Happen?

1. After auto-update, the updater should run a minimal smoke test (at minimum <new_binary> --version with a short timeout) before swapping the active symlink.

If the smoke test fails, the symlink must stay on the previous good version and the failure must be surfaced to the user (stderr line and/or /doctor warning) instead of silently bricking claude.

1. The updater should retain only the current and previous versions in ~/.local/share/claude/versions/ and prune older ones after a successful update, to bound disk usage on hosts with home-directory quotas.
2. Either (a) the bundled Bun runtime should run on RHEL/CentOS 7 / glibc 2.17 hosts, or (b) installation on unsupported hosts should be refused with a clear minimum-glibc/kernel error message instead of silently installing a binary that immediately SIGILLs.

Error Messages/Logs

$ ~/.local/bin/claude --version
  ============================================================
  Bun v1.3.14 (2a41ca97) Linux x64 (baseline)
  Linux Kernel v3.10.0 | glibc v2.17
  CPU: sse42 popcnt avx avx2
  Args: "/home/users/i70653/.local/bin/claude" "--version"
  Elapsed: 6ms | User: 2ms | Sys: 6ms
  RSS: 15.99MB | Peak: 3.50MB | Commit: 15.99MB | Faults: 0

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

  To send a redacted crash report to Bun's team,
  please file a GitHub issue using the link below:

   https://bun.report/1.3.14/B_12a41ca9AA+/xNgr73wCy5/qpC6z0qpCo1yI6iyqpCA4Aw1h0hP

  /bin/bash: line 1: 58597 Illegal instruction     /home/users/i70653/.local/bin/claude --version 2>&1
  exit: 132

  # Same path/binary location, previous version, same shell, same host:
  $ ~/.local/share/claude/versions/2.1.170 --version
  2.1.170 (Claude Code)
  exit: 0

Steps to Reproduce

This bug surfaces in two distinct ways that share the same root cause (auto-updater
swaps the active symlink without validating the new binary). Reproduce either.

### SCENARIO A — Compatibility regression (no space involved)
Host requirements: CentOS / RHEL 7.x with glibc 2.17 and kernel 3.10.x
(any modern x86_64 CPU; AVX/AVX2 present does NOT prevent the crash).
Disk and home-directory quota: ample free space (this scenario is NOT a
space failure — the downloaded binary is intact, it just won't run here).

1. Confirm the host:

cat /etc/redhat-release # CentOS Linux release 7.9.2009 (Core)
ldd --version | head -1 # ldd (GNU libc) 2.17
uname -r # 3.10.0-1160.118.1.el7.x86_64
grep -m1 'model name' /proc/cpuinfo # e.g. Intel Xeon E5-2697A v4
df -h ~/.local/share/claude/ # plenty of free space

1. Have Claude Code 2.1.170 (or any pre-2.1.176 build) installed and working via

the standard installer. Confirm:
~/.local/bin/claude --version # prints e.g. "2.1.170 (Claude Code)"

1. Let the built-in auto-updater run (or trigger it by launching claude); it pulls

2.1.176, drops it into ~/.local/share/claude/versions/2.1.176, and re-points
~/.local/bin/claude at it.

1. Re-invoke claude:

claude --version

Observed: Bun panic / Bus error / "Illegal instruction" / exit 132.
Expected: "2.1.176 (Claude Code)" exit 0.

1. Compare against the previous binary still on disk:

~/.local/share/claude/versions/2.1.170 --version
Returns "2.1.170 (Claude Code)" exit 0 — proves the host is fine; only 2.1.176
is broken.

1. /doctor still reports the update as successful — there is no validation step

that catches the crash.

1. (Optional) md5sum the downloaded 2.1.176 binary and compare across hosts —

identical hash everywhere, ruling out a truncated/corrupt download.

SCENARIO B — Quota / disk-exhaustion during auto-update

Host requirements: any Linux host where ~/.local/share/claude/ lives on a
filesystem with a tight quota — either a standard per-user filesystem quota,
or (very common in enterprise/EDA environments) a NetApp qtree quota enforced
at the storage layer that isn't surfaced via quota / quota -v from inside
the user's shell.

Real-world preconditions seen in the field:

• Old versions are NOT pruned. After several updates, ~/.local/share/claude/

versions/ holds 3+ binaries at ~200-250 MB each (≈700-900 MB total).

• NFS-silly-rename ghost files (.nfs00000...) from previously "removed"

versions linger when a process held the file handle open; they continue
to consume quota until that process exits. Example observed:

$ ls -la ~/.local/share/claude/versions/
2.1.153 239 MB
2.1.170 247 MB
2.1.176 205 MB
.nfs000000008c379999000172f3 231 MB <-- ghost

Even when these are present and consuming hundreds of MB of quota, neither
the installer nor /doctor warns about them.

To reproduce on a host without a "real" quota, simulate one:

1. Cap the install dir's free space so the next download will truncate. One

portable way is a tmpfs overlay sized just under the new binary's size:

sudo mount -t tmpfs -o size=150M tmpfs ~/.local/share/claude/versions/

(or use setquota -u $USER on filesystems that support standard quotas, or
fallocate a sentinel file to fill the volume to a few-MB-of-headroom)

1. Confirm Claude Code is currently installed and working:

claude --version

1. Trigger the auto-update (launch claude or wait for the periodic check).

1. Observe what the updater does on the truncated download:

ls -l ~/.local/share/claude/versions/ # new binary is smaller than expected
md5sum ~/.local/share/claude/versions/<new> # hash differs from a good copy
ls -l ~/.local/bin/claude # symlink has been swapped to the new
# version even though it's truncated
claude --version # ELF error / "unexpected end of file" /
# SIGSEGV / "exec format error"
/doctor # "update success"

Expected: updater detects the failed/truncated download, leaves ~/.local/bin/claude
pointing at the previous good version, and reports the failure to the user.
Observed: symlink swapped, claude unusable, /doctor cheerful.

1. As an additional reproducer for the cleanup half: run multiple successive

updates on a tight-quota host and confirm that old versions/<N.N.NNN>
binaries and .nfs* ghosts continue to accumulate, eventually consuming
enough quota that a subsequent download cannot complete — at which point
Scenario B fires "for real" without any manual simulation.

==========================================================================
Workaround (either scenario)
==========================================================================
ln -sfn ~/.local/share/claude/versions/<last-known-good> ~/.local/bin/claude
rehash # tcsh users — otherwise the cached path stays on the bad binary

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

any

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Xterm

Additional Information

Host details
------------
OS: CentOS Linux 7.9.2009 (Core)
Kernel: 3.10.0-1160.118.1.el7.x86_64
glibc: 2.17
CPU: Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz (Broadwell-EP, 2016)
CPU flags: sse4_2 popcnt avx avx2 bmi1 bmi2
Shell: tcsh
Filesystem of installer target: NFS (NetApp), home-directory layout

Binary state in ~/.local/share/claude/versions/ at time of failure
-----------------------------------------------------------------
-rwxr-xr-x 239896272 Jun 5 2.1.153 (works)
-rwxr-xr-x 247469776 Jun 18 2.1.170 (works)
-rwxr-xr-x 204734464 Jun 21 2.1.176 (CRASHES on --version)
-rwxr-xr-x 230577872 May 19 .nfs000000008c379999000172f3 (orphan NFS-silly-rename ghost
from an earlier "removed" version
still held open by some process —
updater never reclaimed)

MD5s
----
52e055a8d032351c8fca125159eea039 2.1.176
272fae5bf341c6bfb372776fc46eebf2 2.1.170

Bun's own crash submission URL from the panic output:
https://bun.report/1.3.14/B_12a41ca9AA+/xNgr73wCy5/qpC6z0qpCo1yI6iyqpCA4Aw1h0hP

Relation to existing issues
---------------------------
This appears related to the Bun-1.3.14-bundling regression first introduced in 2.1.113 and tracked in:

• #64889 (canonical: Claude Code 2.1.113+ crashes on startup, SIGILL in bundled Bun 1.3.14)
• #63609 (Illegal Instruction crash on CPUs without AVX since v2.1.113)
• #65081 (Bun 1.3.14 crashes on Hyper-V VMs without AVX; should fall back to Node.js)
• #62747 (segfault on startup, all builds since Node→Bun switch)
• #63080 (SIGILL on 2.1.153)

This ticket adds two new angles those existing reports don't cover:
(a) The host has AVX/AVX2 — so the failure mode on glibc 2.17 is not the "no-AVX CPU" path; the
Bun build has an additional kernel/glibc ABI assumption that breaks on RHEL 7.
(b) The auto-updater installed a fundamentally broken binary and reported success — the validation
bug is independent of which runtime is bundled. Adjacent updater issues already filed:
#69842, #69624 (auto-update fails silently, /doctor doesn't catch it), #69884 (installer places
wrong binary on Windows), #69977 (versioned dir never created on remote installs).

Suggested fixes
---------------

1. Smoke-test the freshly-installed binary (e.g. <new> --version with a 5s timeout) before

swapping the active symlink. On failure, leave the symlink on the previous version and surface
the failure via /doctor and stderr.

1. Atomic + revertible install: keep "last-known-good" version metadata so a bad future install

can self-revert.

1. Prune ~/.local/share/claude/versions/ after a successful update — retain only current + previous.
2. Detect NFS silly-renamed ghost files (.nfs* in versions/) and surface them as a warning so users

know to log out / kill stragglers to reclaim disk.

1. Either (a) ship a Bun build that runs on RHEL/CentOS 7 / glibc 2.17 (Red Hat ELS for RHEL 7 runs

through 2024-06+ and RHEL 7-family hosts are widespread in EDA / hardware-verification shops),
or (b) refuse to install on unsupported hosts with a clear "requires glibc >= X.Y" error.

1. Offer an opt-in Node.js-runtime build (as already requested in #65081) for hosts where Bun's

ABI assumptions break.