[Bug] Version 2.1.243 fails to launch on multiple machines, autoupdate causes regression

upvote

Same crash here, with a core dump backtrace that may help narrow it down.

Environment: CachyOS (Arch-based), kernel 7.2.0, x86_64, glibc 2.44, native install (not npm), fish 4.8.1.

Same bisection as the report: 2.1.239 works, 2.1.241 works, 2.1.243 SIGSEGVs (exit 139), no output at all, so --version is enough to reproduce.

I first checked whether the download was simply truncated — it is not. The ELF header is self-consistent with the on-disk size: section headers start at byte 377565848, plus 41 x 64 = 377568472, which is exactly the file size. It is a complete, well-formed binary that faults.

Also of note: 2.1.243 is ~35 MB larger than 2.1.241 (342636848 -> 377568472 bytes), which hints at a toolchain or bundled-runtime change in that release.

Backtrace from coredumpctl info:

Signal: 11 (SEGV) si_code: SEGV_MAPERR
Command Line: /home/<user>/.local/share/claude/versions/2.1.243 --version

#0  0x0000000001d10458 free (2.1.243 + 0x1b10458)
#1  0x00007fc993a3a1ab __newlocale (libc.so.6 + 0x3a1ab)
#2  0x0000000001abd282 n/a (2.1.243 + 0x18bd282)
#3  0x00007fc993ab2584 n/a (libc.so.6 + 0xb2584)
#4  0x00007fc993ab26a9 pthread_once (libc.so.6 + 0xb26a9)
#5  0x0000000001abc2d2 n/a (2.1.243 + 0x18bc2d2)
#6  0x0000000001ace6cf n/a (2.1.243 + 0x18ce6cf)
#7  0x0000000001abdc0a n/a (2.1.243 + 0x18bdc0a)
#8  0x0000000001abe9c4 n/a (2.1.243 + 0x18be9c4)
#9  0x00007fc993ab2584 n/a (libc.so.6 + 0xb2584)
#10 0x00007fc993ab26a9 pthread_once (libc.so.6 + 0xb26a9)
#11 0x0000000001abea15 n/a (2.1.243 + 0x18bea15)
#12 0x0000000001abead7 n/a (2.1.243 + 0x18bead7)
#13 0x0000000001abb922 n/a (2.1.243 + 0x18bb922)
#14 0x0000000001abb724 n/a (2.1.243 + 0x18bb724)
#15 0x0000000001aadadd n/a (2.1.243 + 0x18adadd)
#16 0x00007fc993a27e23 __libc_start_main (libc.so.6 + 0x27e23)
#17 0x0000000001953a2e n/a (2.1.243 + 0x1753a2e)

The crash happens during static initialization, before main — frame #16 is __libc_start_main leading into pthread_once-guarded init routines inside the binary.

The faulting frame is the binary's own bundled free (#0, at an offset inside the 2.1.243 image) being called from the system glibc's __newlocale (#1). That looks like an allocator mismatch: the bundled free interposes the system symbol and is handed a pointer that system glibc allocated during locale setup, then faults with SEGV_MAPERR.

Given that, glibc 2.44 may be the trigger rather than the distro as such — that would explain why it hits some machines and not others. It would be useful if other affected users posted their ldd --version output to confirm or rule out the correlation.

On the autoupdate trap: setting "autoUpdates": false in ~/.claude/settings.json (or exporting DISABLE_AUTOUPDATER=1) makes the rollback stick, so a pinned 2.1.241 survives.

One caveat worth flagging for anyone rolling back on a native install: ~/.claude/chrome/chrome-native-host is a shell wrapper with a hardcoded absolute path into ~/.local/share/claude/versions/<version>. If you delete the old version directory after rolling back, the Chrome extension's native host breaks too.

Same here on Omarchy Quattro.

I had forced mise to upgrade claude.

Lesson learned

Same here on EndeavorOS - exact same error in fish for 2.1.143, not in 2.1.141.

ldd (GNU libc) 2.44
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Just to note this happens on current macOS as well

The SIGSEGV in static init before main is the 2.1.243 artifact itself, not your setup, and that +35MB size delta over 2.1.241 hints at a toolchain change. To break the revert-then-autoupdate loop, add "autoUpdates": false to ~/.claude/settings.json, then install 2.1.241 and it stays. Fresh installs won't help, they just grab 2.1.243 again.