claude --version segfaults (SIGSEGV) immediately on 2.1.243 — 2.1.241 works fine on same system

Status Open

Reported on v2.1.241

Maintainer reply None cached

Activity 0 comments · opened Aug 25, 2026

Title

claude --version segfaults (SIGSEGV) immediately on 2.1.243 — 2.1.241 works fine on same system

Description

Since updating to 2.1.243 (published 2026-08-25 00:08 UTC), claude segfaults immediately on startup — before printing anything, including claude --version.

╭─axel@axel in ~/claude instruct
╰─λ claude
fish: Job 1, 'claude' terminated by signal SIGSEGV (Address boundary error)

╭─axel@axel in ~/claude instruct
╰─λ claude
Segmentation fault         (core dumped) claude

Version bisect (same machine, same OS state, all four binaries still on disk)

export DISABLE_AUTOUPDATER=1
for v in 2.1.232 2.1.234 2.1.241 2.1.243; do
  printf '%-10s ' "$v"
  ~/.local/share/claude/versions/$v --version 2>&1 | tail -1
done

2.1.232    2.1.232 (Claude Code)
2.1.234    2.1.234 (Claude Code)
2.1.241    2.1.241 (Claude Code)
2.1.243

2.1.232, 2.1.234, and 2.1.241 all run cleanly. Only 2.1.243 crashes, and it crashes 100% of the time, tested repeatedly (11 separate coredumps collected).

Binary size progression on linux-x64: 323MB (.232) → 328MB (.234) → 343MB (.241) → 378MB (.243).

Environment

OS: Garuda Linux (Arch-based)
Kernel: 7.1.9-zen1-2-zen
glibc: 2.44+r24+g16be1518495f-1 (ldd --version reports 2.44)
CPU: AMD Ryzen 7700 (AVX2 + AVX-512 capable — not a baseline-build issue)
glibc/gcc-libs/kernel were upgraded 2026-08-24 15:01 UTC, roughly 9 hours before 2.1.243 was published. The bisect above was run entirely on the current (post-upgrade) system, so all four versions were tested under the same glibc/kernel — this isolates the regression to the 2.1.243 build itself, not to the glibc upgrade.

Stack trace (`coredumpctl info`)

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

Stack trace of thread 300416:
#0  0x0000000001d10458 free (2.1.243 + 0x1b10458)
#1  0x00007f14d5e3530a __newlocale (libc.so.6 + 0x3530a)
#2  0x0000000001abd282 n/a (2.1.243 + 0x18bd282)
#3  0x00007f14d5e9d7fc n/a (libc.so.6 + 0x9d7fc)
#4  0x00007f14d5e9d879 pthread_once (libc.so.6 + 0x9d879)
#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  0x00007f14d5e9d7fc n/a (libc.so.6 + 0x9d7fc)
#10 0x00007f14d5e9d879 pthread_once (libc.so.6 + 0x9d879)
#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 0x00007f14d5e27892 __libc_start_main (libc.so.6 + 0x27892)
#17 0x0000000001953a2e n/a (2.1.243 + 0x1753a2e)
ELF object binary architecture: AMD x86-64

The crash is inside free, reached from glibc's __newlocale, itself reached during one-time init (pthread_once) — i.e. this happens during startup locale construction, before the program does anything else. This is consistent across all ~11 crashes observed (identical top frames each time).

Note: I initially suspected an allocator-symbol-interposition issue (the bundled runtime statically linking and exporting its own malloc/free which would preempt glibc's), since the crash is free resolving into the binary itself while called from libc. I checked this directly and want to flag it as ruled out, not a lead:

nm -D --defined-only ~/.local/share/claude/versions/2.1.243 | grep -E ' [TWi] (free|malloc|calloc|realloc)$'
nm -D --defined-only ~/.local/share/claude/versions/2.1.241 | grep -E ' [TWi] (free|malloc|calloc|realloc)$'

Both return no matches — neither binary exports free/malloc/calloc/realloc as global dynamic symbols, so simple symbol interposition isn't the mechanism. I'm not certain what the actual cause is; I'm including the stack trace and bisect so someone with the source/symbols can dig further.

I have not ruled out a locale-related trigger. My locale is en_GB.UTF-8 (present in locale -a as en_GB.utf8), and I also tested with LC_ALL=C LANG=C — the crash was identical, so it does not appear to be a specific missing-locale problem, but the crash mechanically occurs inside __newlocale.

To reproduce

Install 2.1.243 on a similar glibc 2.44 / Arch-based system and run claude --version.

Workaround

Pinning to 2.1.241 (last known-good) resolves it:

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

plus "autoUpdates": false in ~/.claude/settings.json to stop the autoupdater from pulling 2.1.243 back.

Notes

I have the full core dump saved locally if a maintainer needs a specific frame resolved further, but I'm not attaching it here since it's ~70MB of process memory that may contain credentials.
Happy to run additional diagnostics on request — I still have 2.1.232, 2.1.234, 2.1.241, and 2.1.243 all on disk.

---
This issue was filed by Claude (Claude Code) on behalf of the account owner, based on diagnostics gathered on their machine.

View original on GitHub ↗