[BUG] terminated by signal SIGSEGV (Address boundary error)

Same issue. Was working prior to updating. 2.1.241 works fine, auto update from there causes segfault.

Same crash here, adding details + a workaround since the original report has none.

Environment

• Claude Code 2.1.243, native install (~/.local/share/claude/versions/2.1.243, sha256 4b0dafeedd0b469c…, 377,568,472 bytes)
• Arch Linux, kernel 7.1.8-arch1-3, x86_64, glibc 2.44
• CPU: AMD Ryzen 9 7940HS (has avx/avx2/avx512f)
• zsh, kitty terminal
• 2.1.241 works on the same machine; 2.1.240 also fine

Reproduce

$ ~/.local/share/claude/versions/2.1.243 --version
$ echo $?
139

Crashes before printing anything. Same result with a clean environment (env -i HOME=$HOME PATH=/usr/bin …) and from any working directory, so it's not config/env/project related.

Kernel log — same faulting address every run, null-pointer read:

claude[901409]: segfault at 0 ip 0000000001d10458 sp 00007ffe30f97a90 error 4 in 2.1.243[1b0f458,1953000+3b33000]
claude[901451]: segfault at 0 ip 0000000001d10458 sp 00007ffd4816c4c0 error 4 in 2.1.243[1b0f458,1953000+3b33000]
claude[901640]: segfault at 0 ip 0000000001d10458 sp 00007ffeb50634e0 error 4 in 2.1.243[1b0f458,1953000+3b33000]

error 4 = user-mode read of address 0; ip 0x1d10458 is inside the binary's own text segment (offset ≈ 0x201000 from its load base), so this is a bug in the 2.1.243 build itself, not a shared library.

Not a corrupt download: deleted the binary and re-ran claude install 2.1.243 — the new file was byte-identical (cmp) and crashes the same way.

Workaround (native install): point the launcher back at 2.1.241.

ln -sfn ~/.local/share/claude/versions/2.1.241 ~/.local/bin/claude
claude --version   # 2.1.241 (Claude Code)

Don't run claude update until a fixed build ships.

I'm getting the same sort of error on CachyOS (7.2.0-1 kernel:

❯ claude -r
fish: Job 1, 'claude -r' terminated by signal SIGSEGV (Address boundary error)

Root cause: 2.1.243 interposes glibc malloc/free with Bun mimalloc. That free does not no-op on NULL. glibc 2.44 __newlocale calls free(NULL) during early pthread_once locale init, which is valid C, and the process dies.

2.1.241 does not export malloc/free and runs fine on the same machine.

Environment

• CachyOS, kernel 7.1.8-1-cachyos, x86_64, glibc 2.44
• Native binary ~/.local/share/claude/versions/2.1.243
• sha256 4b0dafeedd0b469c41988e200036fd773e7553ba960349c9f02a82c6d1f2ba27 (377,568,472 bytes)
• Embedded runtime: Bun v1.4.0 (19bc277a0) — 2.1.241 is Bun v1.4.0 (fdb5e06cc)

Crash (every invocation, including claude --version; LC_ALL=C does not help)

segfault at 0 ip 0000000001d10458 error 4
#0  free          (2.1.243 + 0x1b10458)  rdi=0
#1  __newlocale   (libc.so.6)
#2  ... bun locale init via pthread_once ...

glibc 2.44 __newlocale zero-initializes an out-param, then always free()s it. ISO C requires free(NULL) to be a no-op. 2.1.243’s interposed free (0x1d10430) has no NULL check and immediately does mov (%rax,%rcx,1),%rdi with rax=0.

Regression vs 2.1.241

| | 2.1.241 | 2.1.243 |
|---|---|---|
| malloc/free in dynsym | not exported (UND libc) | GLOBAL malloc@@GLIBC_2.2.5 / free@@GLIBC_2.2.5 (also __libc_free) |
| claude --version | works | SIGSEGV 139 |

Fix: restore a NULL guard on the interposed free (and don’t export allocator symbols until mimalloc is ready), or stop interposing malloc/free the way 2.1.241 did.

Workaround: ln -sfn ~/.local/share/claude/versions/2.1.241 ~/.local/bin/claude — do not claude update until a new build ships.

Same issue and diagnosis (via claude, lol) as @ytcs.

       Message: Process 146704 (claude) of user 1000 dumped core.
                
                Stack trace of thread 146704:
                #0  0x0000000001d10458 free (2.1.243 + 0x1b10458)
                #1  0x00007fb78f43530a __newlocale (libc.so.6 + 0x3530a)