[BUG] 2.1.243 Segmentation fault

STACK TRACE

Signal: 11 (SEGV) si_code: SEGV_MAPERR

#0 0x0000000001d10458 free (2.1.243 + 0x1b10458)
#1 0x00007f5868c3a1ab __newlocale (libc.so.6 + 0x3a1ab)
#2 0x0000000001abd282 n/a (2.1.243 + 0x18bd282)
#3 0x00007f5868cb2284 n/a (libc.so.6 + 0xb2284)
#4 0x00007f5868cb23a9 pthread_once (libc.so.6 + 0xb23a9)
#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 0x00007f5868cb2284 n/a (libc.so.6 + 0xb2284)
#10 0x00007f5868cb23a9 pthread_once (libc.so.6 + 0xb23a9)
#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 0x00007f5868c27e23 __libc_start_main (libc.so.6 + 0x27e23)
#17 0x0000000001953a2e n/a (2.1.243 + 0x1753a2e)

the stack trace if it helps

Same here... segmentation fault...

I independently reproduced this on Claude Code 2.1.243 and collected a core dump. This is a startup regression in the native binary, not a permissions/configuration issue.

Environment

• Linux x86-64 (Arch-based distribution)
• Kernel: 7.1.8-1-cachyos
• glibc: 2.44
• Native Claude Code installation
• 2.1.243 ELF build ID: c39577b41056cc1abf1ea7ed72a8b4c1ba407c42

Minimal reproduction

claude --version
echo $?

Result:

Segmentation fault (core dumped)
139

The crash also occurs with a nearly empty environment:

env -i HOME=/tmp PATH=/usr/bin:/bin LANG=C <install-dir>/2.1.243 --version

Therefore --dangerously-skip-permissions, user configuration, shell integration, locale environment variables, and project contents are not required to trigger it.

Adjacent-version comparison

All binaries below were executed directly on the same machine and glibc:

2.1.239: 2.1.239 (Claude Code), exit 0
2.1.240: 2.1.240 (Claude Code), exit 0
2.1.241: 2.1.241 (Claude Code), exit 0
2.1.243: SIGSEGV, exit 139

Core dump

Signal: 11 (SEGV), si_code: SEGV_MAPERR
#0  free                  (Claude Code 2.1.243 + 0x1b10458)
#1  __newlocale           (libc.so.6 + 0x39d0b)
#2  <unknown>             (Claude Code 2.1.243 + 0x18bd282)
#3  <unknown>             (libc.so.6 + 0xb2cc4)
#4  pthread_once          (libc.so.6 + 0xb2df9)
...
#16 __libc_start_main     (libc.so.6 + 0x27da3)

Allocator-symbol regression

2.1.241 does not expose allocator symbols in its dynamic symbol table. In contrast, 2.1.243 exports versioned allocator symbols including:

calloc@@GLIBC_2.2.5
malloc@@GLIBC_2.2.5
free@@GLIBC_2.2.5
__libc_malloc@@GLIBC_2.2.5
__libc_free@@GLIBC_2.2.5
realloc@@GLIBC_2.2.5

The fault is inside the executable's exported free() while called from glibc __newlocale(). This matches the allocator interposition / missing free(NULL) guard root cause documented in #89334. It appears that the defective allocator export introduced in 2.1.242 is also present in 2.1.243.

Workaround

Running 2.1.241 directly works. Repointing the launcher to 2.1.241 and temporarily disabling auto-update also restores operation:

ln -sfn <install-dir>/2.1.241 <launcher-path>/claude
DISABLE_AUTOUPDATER=1 claude --version

This report intentionally omits usernames, hostnames, machine identifiers, process IDs, project paths, and configuration contents.

im so sick of them bruh does anyone know of a harness on par with features that i could migrate to? claude has been performing so bad lately too

+1, this version must be pulled immediately

One additional data point: I directly tested the 2.1.242 npm platform package as well as 2.1.243 through both distribution paths on Manjaro Linux x86-64 (6.6.148-1-MANJARO, glibc 2.44).

2.1.241 native: works, exit 0
  Build ID: d11007948a6167b426d967c295579e51ded8d0b6

2.1.242 npm/Bun: SIGSEGV, exit 139
  Build ID: c39577b41056cc1abf1ea7ed72a8b4c1ba407c42
  SHA-256: 528ef039aa7d64d7b3fbc06925132755a516b4dcaad784cf0b51fe03167360d4

2.1.243 native and npm/Bun: SIGSEGV, exit 139
  Build ID: c39577b41056cc1abf1ea7ed72a8b4c1ba407c42
  SHA-256: 4b0dafeedd0b469c41988e200036fd773e7553ba960349c9f02a82c6d1f2ba27

The native and npm/Bun 2.1.243 binaries are byte-for-byte identical. Versions 2.1.242 and 2.1.243 have different hashes but share the same ELF build ID. This directly confirms that 2.1.242 is also affected and that the 2.1.243 failure is independent of the native versus npm distribution path.

Root cause, for whoever picks this up: 2.1.243 exports its bundled allocator's malloc/free/calloc/realloc as GLOBAL DEFAULT dynamic symbols. 2.1.241 does not. That single ABI change explains the whole crash.

$ readelf -W --dyn-syms 2.1.243 | grep -wE 'malloc|free|calloc|realloc|aligned_alloc|posix_memalign' | grep -v UND
   560: 0000000001d10320   145 FUNC  GLOBAL DEFAULT  17 calloc@@GLIBC_2.2.5
   700: 0000000001d102d0    79 FUNC  GLOBAL DEFAULT  17 malloc@@GLIBC_2.2.5
   862: 0000000001d10b70   122 FUNC  GLOBAL DEFAULT  17 aligned_alloc@@GLIBC_2.16
   927: 0000000001d10ab0   181 FUNC  GLOBAL DEFAULT  17 posix_memalign@@GLIBC_2.2.5
  1048: 0000000001d10430   126 FUNC  GLOBAL DEFAULT  17 free@@GLIBC_2.2.5
  1213: 0000000001d103c0    98 FUNC  GLOBAL DEFAULT  17 realloc@@GLIBC_2.2.5

$ readelf -W --dyn-syms 2.1.241 | grep -wE 'malloc|free|calloc|realloc|aligned_alloc|posix_memalign' | grep -v UND
(no output)

The executable sits at the head of the global symbol lookup scope, so these definitions win over libc.so.6 for every unqualified binding — including glibc's own internal calls. glibc allocates with its real malloc during early static init, then __newlocale hands the pointer to what it thinks is its own free, and the call lands in the bundled allocator instead. That allocator has no metadata for the address, so it faults.

This matches the reported stack exactly:

  0:  free        (2.1.243 + 0x1b10458)   <- 0x1d10458 file / 0x1b10458 vaddr-biased
  1:  __newlocale (libc.so.6 + 0x3a1ab)
  ...
 16:  __libc_start_main

The crash PC 0x1d10458 falls inside free@@GLIBC_2.2.5 (0x1d10430 + 126 bytes = 0x1d104ae). Not a coincidental frame — it is the exported interposer itself.

Two things this explains:

• Why it is 100% deterministic and pre-main. It is on the __libc_start_main to pthread_once static-init path, before any config, TTY, network, or argv handling. Hence --version failing, and seanGSISG's env -i repro still crashing.
• The new GLIBC_2.16 requirement anyone may notice when diffing verdefs — that is just aligned_alloc@@GLIBC_2.16 arriving with the rest of the interposed set. A symptom, not the cause; glibc 2.44 satisfies it fine.

Also worth recording: the 2.1.243 payload is not truncated or corrupt, which was my first guess given the ~35 MB size jump over 2.1.241. The Bun trailer is intact and self-consistent in both builds — the embedded-payload offset lands 3,028 bytes from EOF in 2.1.241 and 3,027 in 2.1.243. The file is complete; this is a link-time regression.

Suggested fix: restore the pre-2.1.242 linkage so the allocator is not exported — hide it (-fvisibility=hidden, or a version script with local: malloc; free; calloc; realloc; aligned_alloc; posix_memalign;), or link it statically without export. If the interposition is deliberate, it has to be complete and consistent enough to own every pointer glibc frees, which on the static-init path it cannot be.

Environment, matching the others: Linux x86-64, kernel 7.1.1-2-cachyos, glibc 2.44, native install, 2.1.243 build ID c39577b41056cc1abf1ea7ed72a8b4c1ba407c42.

Workaround until a fixed build ships — repoint the symlink at the last good version:

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

Same issue, same findings, had to disable auto-updates and symlink 2.1.241

Environment
Linux x86-64 (Archlinux)
Kernel 7.1.9-arch1-2
glibc 2.44+r24+g16be1518495f-1
Native Claude Code installation

Same issue here, they definitely broke something. I'm also on Arch-derived

After rolling back the symlink:

DISABLE_AUTOUPDATER=1 claude

will prevent claude from updating and crashing as soon as you start it

Reproduced on another Arch machine (Omarchy), same stack, same free() ← __newlocale ← pthread_once startup chain:

• Kernel 7.1.8-arch1-3, glibc 2.44+r24+g16be1518495f-1
• Installed via mise (aqua:anthropics/claude-code), claude-linux-x64.tar.gz, checksum verified
• claude --version → SIGSEGV SEGV_MAPERR, exit 139, 3/3 runs; not OOM
• 2.1.241 on the identical glibc works fine

#0  0x0000000001d10458 free       (claude + 0x1b10458)
#1  0x00007f939803530a __newlocale (libc.so.6 + 0x3530a)
#2  0x0000000001abd282 n/a        (claude + 0x18bd282)
#3  0x00007f939809d7fc n/a        (libc.so.6 + 0x9d7fc)
#4  0x00007f939809d879 pthread_once (libc.so.6 + 0x9d879)
...
#16 0x00007f9398027892 __libc_start_main (libc.so.6 + 0x27892)

Frame 0 resolves to the binary's own exported free (bundled allocator) being handed a pointer glibc's newlocale allocated internally — looks like an allocator-interposition mismatch with glibc 2.44.

Same issue on Arch Linux, native install. Disabled auto-updates and rolled back

Same here, CachyOS.

I asked google AI, it tells me to ``rm -rf ~/.local/share/claude``, then I don't have claude .
Fortunately, I have a running claude, and it

cp /proc/33140/exe ~/.local/share/claude/versions/2.1.241
ln -sfn ~/.local/share/claude/versions/2.1.241 ~/.local/bin/claude

and recovered the old version. That's actually smart

Confirming the same crash on another glibc 2.44 machine.

Environment

• CachyOS Linux, kernel 7.1.6-1-cachyos, x86-64
• glibc 2.44+r5+g7cba77790f32-1 (ldd (GNU libc) 2.44)
• Installed via the official installer (~/.local/share/claude/versions/); auto-updated to 2.1.243 at 2026-08-25 05:55 IST

Symptoms

• claude --version segfaults immediately (exit 139), no output — SIGSEGV, si_code: SEGV_MAPERR
• Not a corrupt download: my binary's sha256 4b0dafeedd0b469c41988e200036fd773e7553ba960349c9f02a82c6d1f2ba27 matches downloads.claude.ai/claude-code-releases/2.1.243/manifest.json for linux-x64 exactly (size 377568472)
• Crashes identically under LC_ALL=C (default locale here is en_IN)
• 2.1.241 (BuildID d11007948a6167b426d967c295579e51ded8d0b6) runs fine on the same machine; 2.1.243 has BuildID c39577b41056cc1abf1ea7ed72a8b4c1ba407c42

Stack trace (coredumpctl info)

Signal: 11 (SEGV) si_code: SEGV_MAPERR

#0  0x0000000001d10458 free (2.1.243 + 0x1b10458)
#1  0x00007f7e8c439d0b __newlocale (libc.so.6 + 0x39d0b)
#2  0x0000000001abd282 n/a (2.1.243 + 0x18bd282)
#3  0x00007f7e8c4b2b44 n/a (libc.so.6 + 0xb2b44)
#4  0x00007f7e8c4b2c79 pthread_once (libc.so.6 + 0xb2c79)
#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  0x00007f7e8c4b2b44 n/a (libc.so.6 + 0xb2b44)
#10 0x00007f7e8c4b2c79 pthread_once (libc.so.6 + 0xb2c79)
#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 0x00007f7e8c427da3 __libc_start_main (libc.so.6 + 0x27da3)
#17 0x0000000001953a2e n/a (2.1.243 + 0x1753a2e)

Frame #0 offset (+0x1b10458) matches the ip reported in #89369's dmesg line exactly, consistent with the diagnosed free(NULL)-from-__newlocale path in the interposed allocator.

Workaround that restored service here: re-point the version symlink to the previous build and stop the updater from reinstalling the broken one —

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

plus "env": {"DISABLE_AUTOUPDATER": "1"} in ~/.claude/settings.json. (The stable channel currently serves 2.1.231, so pinning 2.1.241 beats downgrading.)

Please add Arch to your test matrix, Anthropic :pray:

have this issue for cachyos too

lol Claude Code CLI breaks, the internet grinds to a halt! XD

nah, its just reverting back to older version and dont update to patch 2.1.243. just first time seeing segfaults....

Do they not have automated tests to catch this sort of thing? How can a segmentation fault preventing the whole app from launching make it into production?

they dont test on every OS i suppose, from what i understand arch linux generally have bleeding edge version of the package etc and claude code or whatever their dependencies under does not cater well to latest glibc versions?

With their resources that is not much to ask for. They could at least be testing at least debian, fedora, and arch to see if the app even boots.

they only care to get the rl data from us bro we gotta chill. we're only their lab rats until we pay em api prices.

i was manually looking at other issues, they pointed out issue with the latest version of glibc, only archlinux will use latest version while other distro or "windows" "macos" will not be as updated.

Quick Fix on Linux:

Check other installed versions:

[!NOTE] The problem is with version 2.1.243

ls ~/.local/share/claude/versions/

You might see something like:

$ ls ~/.local/share/claude/versions/
2.1.239  2.1.240  2.1.241  2.1.243

Check latest working version:

~/.local/share/claude/versions/2.1.241 --version

You can try version 2.1.239 or whatever you have.

Then, make it your default:

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

Lastly, disable auto-update for now by modifying ~/.claude/settings.json file, and add:

{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  }
}

Measurements are collected in #89368: a glibc bisect across eight builds, a ~15-line reproducer that does not need the 377 MB binary, and evidence that the trigger is a build property rather than a glibc version.

Confirming on Arch Linux, glibc 2.44+r24, x86_64 (avx2): 2.1.243 segfaults 3/3 on claude --version (SIGSEGV, exit 139, no output — crash precedes any banner). Core trace shows __newlocale (libc) → free resolving into the app image, consistent with the mimalloc/newlocale conflict in #89394.

Ruling out download corruption definitively: local binary sha256 4b0dafeedd0b469c41988e200036fd773e7553ba960349c9f02a82c6d1f2ba27, size 377568472 — byte-identical to platforms["linux-x64"].checksum in the official downloads.claude.ai/claude-code-releases/2.1.243/manifest.json, and identical to the npm @anthropic-ai/claude-code-linux-x64@2.1.243 tarball binary. Same bytes from both channels, both verified, both crash.

2.1.241 runs clean on the same machine.

Believe the issue is limited to Arch - has anyone repro'd on a different distribution?

Also hitting this on Arch. One thing that might be useful: my CPU has AVX-512, and it still crashes, so this isn't limited to the avx2 path @statik1 was on.

Setup:

• Arch Linux x86_64, kernel 7.1.9-arch1-2
• glibc 2.44+r24+g16be1518495f-1
• AMD Ryzen 7 8700F, 8c/8t, with avx512bw, avx512dq, avx512cd, avx512_bf16, avx512_bitalg
• 2.1.243 segfaults, 2.1.241 works on the same machine right now

My binary is the same one @statik1 checksummed:

sha256  4b0dafeedd0b469c41988e200036fd773e7553ba960349c9f02a82c6d1f2ba27
size    377568472

Same bytes, different CPU feature level, same crash. So CPU dispatch probably isn't the trigger.

The crash also doesn't depend on the environment. claude --version exits 139 under en_US.utf8, en_US.UTF-8, C.utf8, C, with those vars unset, and under env -i with nothing set at all. I checked because the __newlocale frame makes it look like a locale misconfiguration, and it isn't one. That matches the allocator interposition analysis in #89368 and #89394.

Signal: 11 (SEGV) si_code: SEGV_MAPERR   si_addr=NULL

#0  0x0000000001d10458 free (2.1.243 + 0x1b10458)     <-- in the executable
#1  0x00007f26d7c3530a __newlocale (libc.so.6 + 0x3530a)
#2  0x0000000001abd282 n/a (2.1.243 + 0x18bd282)
#3  0x00007f26d7c9d7fc n/a (libc.so.6 + 0x9d7fc)
#4  0x00007f26d7c9d879 pthread_once (libc.so.6 + 0x9d879)

strace shows the SIGSEGV right after libm.so.6 is mapped, before any application syscalls.

Worth noting glibc hasn't moved on my box since 2026-08-12, and 2.1.241 still runs fine under that same glibc today. So the glibc version alone doesn't explain it, which lines up with what @kay-ws found in #89368.

@MrTpat on the other-distro question: #89377 and #89412 are CachyOS, #89371 is CachyOS via the native installer, and #89368 is Manjaro. All Arch derivatives though, so I don't think anyone has ruled out a non-Arch distro on glibc 2.44 yet.

Same crash, same fault address (ip 0000000001d10458) on EndeavourOS (Arch-based).
In my case it surfaces through the VS Code extension (bundled binary at
extensions/anthropic.claude-code-2.1.243-linux-x64/resources/native-binary/claude)
rather than bare CLI invocation — the process launches successfully and runs for
~4s before segfaulting on session resume/switch or /context, rather than crashing
immediately on --version. My standalone CLI at 2.1.245 (~/.local/bin/claude) does
not reproduce this at all. Workaround: setting claudeCode.claudeProcessWrapper in
VS Code settings.json to point at the working 2.1.245 standalone binary avoids the
extension's bundled 2.1.243 entirely.

claude[158372]: segfault at 0 ip 0000000001d10458 sp 00007ffffcad8470 error 4 in claude[1b0f458,1953000+3b33000]
claude[159146]: segfault at 0 ip 0000000001d10458 sp 00007fffcaf7b410 error 4 in claude[1b0f458,1953000+3b33000]
claude[159218]: segfault at 0 ip 0000000001d10458 sp 00007ffec93f8da0 error 4 in claude[1b0f458,1953000+3b33000]

fixed with .245