Deterministic SIGSEGV on claude CLI startup (free/__newlocale/pthread_once)

Status Open

Maintainer reply None cached

Activity 7 comments · opened Aug 25, 2026

Claude Code CLI: deterministic SIGSEGV on process startup

Summary

Every fresh invocation of the claude binary segfaults during startup, before
producing any output — including claude --version. Reproduced 100% of the
time (3/3 just now, plus ~20 crashes over a prior ~10-minute window). A
long-running interactive session that has already gotten past whatever
initializes on startup keeps working fine; it's new process launches that die.

Environment

OS: Arch Linux (rolling), kernel 7.1.8-arch1-3
Two affected installs, same crash signature on both:
App-installed: /home/losera/.local/share/claude/versions/2.1.243
npm/mise-installed: /home/losera/.local/share/mise/installs/node/22.23.2/lib/node_modules/@anthropic-ai/claude-code/bin/claude.exe

Reproduction

$ claude --version
Segmentation fault (core dumped)

No arguments needed. Also reliably triggered by the CLI's own shell integration:
the injected grep/find shell functions shell out to claude (as
ARGV0=ugrep/ARGV0=bfs) to provide fast search — every such invocation
crashed too, until routed around via command grep/command find.

Crash signature (from `coredumpctl`, identical across every occurrence)

Signal: 11 (SEGV) si_code: SEGV_MAPERR
Stack trace:
 #0 free
 #1 __newlocale        (libc.so.6)
 #2 n/a                 (claude.exe)
 #3 n/a                 (libc.so.6)
 #4 pthread_once        (libc.so.6)
 #5-8 n/a                (claude.exe)
 #9 n/a                 (libc.so.6)
 #10 pthread_once       (libc.so.6)
 #11-15 n/a              (claude.exe)
 #16 __libc_start_main  (libc.so.6)
 #17 n/a                (claude.exe)

Pattern: a pthread_once-guarded one-time initializer (__newlocale) calling
free(), crashing with SEGV_MAPERR (invalid address, not just a null
deref). Reads like a race or reentrancy bug in one-time locale
initialization — consistent with why a process that's already past init
(this interactive session) keeps running, while every new process launch
(--version, or the grep/find subprocess spawns) dies before doing anything
else.

Timeline

19:57:55–20:02:22 EDT — 7 crashes of the top-level claude process

(version 2.1.243), one apparently mid-interactive-session in a tmux pane.

20:05:19–20:08:06 EDT — crashes shift to the mise-installed

claude.exe, including via the grep/find shell-integration subprocess path.

20:29:26 EDT (just now) — reconfirmed live: 3/3 fresh claude --version

invocations crash identically.

Impact

Kills interactive sessions outright when hit mid-session.
Breaks the CLI's own grep/find shell integration on every call.
claude --version cannot even report a version right now on this machine.

Ruled out

Locale env is standard, not something exotic: LANG=en_US.UTF-8, all

LC_* inherit from it, LC_ALL unset. Not an obvious misconfiguration on
this end, despite the crash being inside __newlocale.

Not yet determined

Root cause inside claude.exe (frames are n/a — no symbols available

locally; raw core files are retained under
/var/lib/systemd/coredump/core.claude* if useful).

Whether it's specific to this machine's locale/glibc configuration, or

reproducible more broadly.

View original on GitHub ↗

7 Comments

neunenak · 6 days ago

I believe I'm hitting the same issue, after the most recent update today. Arch Linux x86-64 machine.

ToddServo · 6 days ago

Same issue here, same machine.

Losera · 6 days ago

Update: pinpointed this to a specific bad release, and found a working workaround.

Root cause of the crash storm (not just a flaky repro): ~/.local/share/claude/versions/2.1.243 was auto-installed today at the exact moment the segfault storm began. Directly invoking the two previous cached versions on the same machine, same environment, is 100% clean:

$ /home/losera/.local/share/claude/versions/2.1.241 --version
2.1.241 (Claude Code)   # works, repeated 4x
$ /home/losera/.local/share/claude/versions/2.1.240 --version
2.1.240 (Claude Code)   # works, repeated 2x
$ /home/losera/.local/share/claude/versions/2.1.243 --version
Segmentation fault (core dumped)   # crashes 100% of the time

Same machine, same locale, same everything — only the binary differs. This strongly suggests 2.1.243 itself introduced the regression rather than anything environment-specific.

Workaround: repoint whichever claude symlink wins in your PATH at the last known-good cached version, e.g.:

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

Note there can be two independent launch paths that both need fixing if you have both the app-installer and an npm/mise install — in my case ~/.local/share/mise/installs/node/22/bin/claude (symlinked into @anthropic-ai/claude-code's own bin/claude.exe) was also pinned to the same broken 2.1.243 and took priority in PATH over the app-installed one.

Hope this narrows it down quickly — happy to pull anything else off this machine (both 2.1.243 binaries and their npm package are still present locally).

neunenak · 6 days ago

Update: pinpointed this to a specific bad release, and found a working workaround. Root cause of the crash storm (not just a flaky repro): ~/.local/share/claude/versions/2.1.243 was auto-installed today at the exact moment the segfault storm began. Directly invoking the two previous cached versions on the same machine, same environment, is 100% clean: `` $ /home/losera/.local/share/claude/versions/2.1.241 --version 2.1.241 (Claude Code) # works, repeated 4x $ /home/losera/.local/share/claude/versions/2.1.240 --version 2.1.240 (Claude Code) # works, repeated 2x $ /home/losera/.local/share/claude/versions/2.1.243 --version Segmentation fault (core dumped) # crashes 100% of the time ` Same machine, same locale, same everything — only the binary differs. This strongly suggests 2.1.243 itself introduced the regression rather than anything environment-specific. **Workaround:** repoint whichever claude symlink wins in your PATH at the last known-good cached version, e.g.: ` ln -sfn ~/.local/share/claude/versions/2.1.241 ~/.local/bin/claude ` Note there can be _two_ independent launch paths that both need fixing if you have both the app-installer and an npm/mise install — in my case ~/.local/share/mise/installs/node/22/bin/claude (symlinked into @anthropic-ai/claude-code's own bin/claude.exe) was also pinned to the same broken 2.1.243 and took priority in PATH over the app-installed one. Hope this narrows it down quickly — happy to pull anything else off this machine (both 2.1.243` binaries and their npm package are still present locally).

I can confirm this fix worked for me, so additional evidence that version .243 broke in some way

jgyy · 6 days ago

ln -sfn ~/.local/share/claude/versions/2.1.241 ~/.local/bin/claude # i did this too, but once 2.1.244 is out i will disable this symbolic link

zytoc · 6 days ago

#89371

BGLuis · 6 days ago

Confirming reproduction on another distro with the same exact crash address as the OP's gdb trace (0x1d10458 in free), same call chain (free <- __newlocale <- pthread_once):

Environment:

Distro: Arch Linux (rolling, native package claude-code 2.1.241-1 from extra, not AUR)
Kernel: 7.1.9-arch1-2
glibc: 2.44
uname -m: x86_64

Reproduced via two independent distribution channels, both segfaulting identically:

Official install.sh (downloads native linux-x64 binary) → claude-2.1.243-linux-x64 install segfaults immediately.
npm install -g @anthropic-ai/claude-code (2.1.243) → claude.exe segfaults on invocation.

coredumpctl backtrace (10 crashes collected across both channels, all identical):

#0  free (claude-2.1.243-linux-x64 + 0x1b10458)
#1  __newlocale (libc.so.6 + 0x3530a)
#2  ?? (claude-2.1.243-linux-x64 + 0x18bd282)
#3  ?? (libc.so.6 + 0x9d7fc)
#4  pthread_once (libc.so.6 + 0x9d879)
...

si_code: SEGV_MAPERR, signal 11.

Workaround: staying on 2.1.241 (still installable via the AUR/native package) does not exhibit this crash — matches other reports that 2.1.242/2.1.243 introduced the regression.

This matches the root cause already identified in #89389 (interposed mimalloc free lacking a NULL check, hit by glibc 2.44's newlocale pre-main init) — adding this as another confirmed data point on Arch specifically, in case distro/glibc-version breadth is useful for prioritization.