Native binary 2.1.242 segfaults deterministically on startup (linux-surface kernel, x86_64) — 2.1.239-2.1.241 work fine

Preflight Checklist

• [x] I searched existing issues for the same segfault/crash on startup and did not find a match for 2.1.242 specifically.
• [x] I confirmed this is reproducible on a clean invocation (claude --version), not tied to a specific project, session, or command flags.
• [x] I bisected across recent versions: 2.1.239, 2.1.240, and 2.1.241 all run correctly on this exact machine; only 2.1.242 crashes.
• [x] I collected kernel-level crash evidence (journalctl -k) showing the same faulting instruction address across multiple independent runs and CPU cores.

Environment

• Claude Code version (crashing): 2.1.242
• Claude Code versions confirmed working (same machine): 2.1.239, 2.1.240, 2.1.241
• Install/binary type: Native binary (non-npm), managed via ~/.local/bin/claude symlink to ~/.local/share/claude/versions/<version>
• OS: Arch Linux (rolling)
• Kernel: 6.19.8-arch1-3-surface (Surface-patched kernel, SMP PREEMPT_DYNAMIC)
• glibc: 2.44
• Architecture: x86_64
• CPU: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz (Microsoft Surface device)
• Auto-updater: enabled by default; disabled via DISABLE_AUTOUPDATER=1 as part of the workaround below

Bug Description

Starting with version 2.1.242, the native Claude Code binary segfaults deterministically on every invocation, including the most minimal possible one (claude --version), before any session, network call, or config loading appears to occur. The crash happens at the exact same instruction address on every run, across different CPU cores, which points to a deterministic code-path bug (e.g. bad codegen, illegal instruction reached via a corrupted jump table, or a null/invalid function pointer dereference) rather than a race condition, memory corruption from external state, or hardware issue.

Versions 2.1.239, 2.1.240, and 2.1.241 all run correctly on the identical system (same kernel, same glibc, same hardware), isolating the regression specifically to whatever changed in the 2.1.242 build.

Steps to Reproduce

1. On Arch Linux, kernel 6.19.8-arch1-3-surface, glibc 2.44, x86_64.
2. Install/update Claude Code native binary to version 2.1.242.
3. Run:

``
claude --version
``

1. Observe the process crash immediately with a segmentation fault (no stdout output, no error message to the terminal beyond the shell reporting the process was killed).
2. Confirm in kernel logs via:

``
journalctl -k --no-pager | grep -i segfault
``

Expected Behavior

claude --version (and normal claude startup) should print the version string and exit/start normally, as it does on 2.1.239, 2.1.240, and 2.1.241 on this same machine.

Actual Behavior

The process segfaults immediately, with no useful error surfaced to the terminal. The kernel log records the same fault signature on every occurrence:

segfault at 0 ip 0000000001d10458 sp 00007ffc72100de0 error 4 in 2.1.242[1b0f458,1953000+3b33000] likely on CPU 3 (core 3, socket 0)

This is fully deterministic and reproducible — the same faulting instruction pointer (0000000001d10458) and the same module base/offset (1b0f458,1953000+3b33000) appear across many independent runs, on different CPU cores/sockets each time (ruling out a hardware/thermal issue tied to one core):

ago 28 17:09:44 SurfaceJH kernel: claude[8668]: segfault at 0 ip 0000000001d10458 sp 00007ffc72100de0 error 4 in 2.1.242[1b0f458,1953000+3b33000] likely on CPU 3 (core 3, socket 0)
ago 28 17:09:58 SurfaceJH kernel: claude[8699]: segfault at 0 ip 0000000001d10458 sp 00007ffcaf9f5080 error 4 in 2.1.242[1b0f458,1953000+3b33000] likely on CPU 2 (core 2, socket 0)
ago 28 17:41:29 SurfaceJH kernel: claude[11027]: segfault at 0 ip 0000000001d10458 sp 00007fff7671c680 error 4 in 2.1.242[1b0f458,1953000+3b33000] likely on CPU 6 (core 2, socket 0)
ago 28 17:42:50 SurfaceJH kernel: claude[11169]: segfault at 0 ip 0000000001d10458 sp 00007ffe26241690 error 4 in 2.1.242[1b0f458,1953000+3b33000] likely on CPU 7 (core 3, socket 0)
ago 28 17:45:19 SurfaceJH kernel: claude[11602]: segfault at 0 ip 0000000001d10458 sp 00007ffdb03f2460 error 4 in 2.1.242[1b0f458,1953000+3b33000] likely on CPU 5 (core 1, socket 0)
ago 28 17:46:32 SurfaceJH kernel: claude[11673]: segfault at 0 ip 0000000001d10458 sp 00007ffd770be420 error 4 in 2.1.242[1b0f458,1953000+3b33000] likely on CPU 4 (core 0, socket 0)
ago 28 17:50:04 SurfaceJH kernel: claude[11838]: segfault at 0 ip 0000000001d10458 sp 00007ffdfb8eee30 error 4 in 2.1.242[1b0f458,1953000+3b33000] likely on CPU 1 (core 1, socket 0)
ago 28 17:52:04 SurfaceJH kernel: claude[11989]: segfault at 0 ip 0000000001d10458 sp 00007ffc14a822b0 error 4 in 2.1.242[1b0f458,1953000+3b33000] likely on CPU 3 (core 3, socket 0)
ago 28 17:57:02 SurfaceJH kernel: claude[12239]: segfault at 0 ip 0000000001d10458 sp 00007ffe7042d9e0 error 4 in 2.1.242[1b0f458,1953000+3b33000] likely on CPU 6 (core 2, socket 0)
ago 28 18:02:49 SurfaceJH kernel: 2.1.242[13487]: segfault at 0 ip 0000000001d10458 sp 00007ffe46a473a0 error 4 in 2.1.242[1b0f458,1953000+3b33000] likely on CPU 3 (core 3, socket 0)

(Timestamps are in local time, Mon DD HH:MM:SS format from journalctl -k, host SurfaceJH.)

Note error 4 (write, in-kernel page-fault error code with the user-mode bit set, no protection-violation bit) and segfault at 0, i.e. a fault dereferencing address 0x0 — consistent with a null-pointer read/jump rather than a stack overflow or heap corruption at a random address.

Additional Context

• Regression isolation: 2.1.239, 2.1.240, and 2.1.241 all start and run correctly on this exact machine (same kernel, same glibc, same hardware, same ~/.claude config/state). Only 2.1.242 exhibits this crash, and it does so on 100% of invocations, including bare claude --version with no session/config initialization required. This strongly suggests the regression was introduced in whatever changed between 2.1.241 and 2.1.242.
• Not network/permissions related: The crash occurs before any network call or auth flow would run (--version alone triggers it), so this does not appear related to connectivity, proxy config, or file permissions.
• Workaround currently in use:

1. Pin the working binary via symlink:

``
ln -sf ~/.local/share/claude/versions/2.1.241 ~/.local/bin/claude
``

1. Prevent the auto-updater from reintroducing 2.1.242:

``
export DISABLE_AUTOUPDATER=1
``

• Hardware note: This is a Microsoft Surface device running a Surface-patched kernel (linux-surface/6.19.8-arch1-3-surface). If this turns out to be relevant (e.g. an issue specific to certain CPU microarchitectures or a code path only reached on non-standard kernel builds), happy to provide more low-level detail (e.g. disassembly around the faulting offset 1953000+3b33000 / IP 0x1d10458, /proc/cpuinfo flags, core dump if one can be captured) — please let me know what would help narrow this down.