[Bug] Claude Code 2.1.243 crashes with SIGSEGV on startup (null pointer dereference)

Status Open
Reported on v2.1.241
Maintainer reply None cached
Activity 5 comments · opened Aug 25, 2026

Bug Description
Title: 2.1.243 segfaults on startup (null deref at fixed address) on Linux x86_64; 2.1.241 fine

SUMMARY
Claude Code 2.1.243 crashes with SIGSEGV immediately on launch, before any UI
appears. Every invocation fails, including claude --version, from any working
directory. Rolling the version symlink back to 2.1.241 fixes it completely.
This looks like a bad release build rather than a machine-specific problem:
2.1.239, 2.1.240 and 2.1.241 are all installed on this machine and all start
normally.

REPRODUCTION

  1. Be on 2.1.243 (installed by auto-update on 2026-08-24 18:45; the launcher

symlink was repointed to it at 19:01).

  1. Run claude -- or even claude --version -- from any directory.
  2. Process dies immediately:

fish: Job 1, 'claude' terminated by signal SIGSEGV (Address boundary error)
Exit code 139.

100% reproducible. Shell-independent (reproduced from fish and from a
non-interactive bash invocation).

VERSION COMPARISON (same machine, same user, run back to back)
<versions-dir>/2.1.239 --version -> exit 0, "2.1.239 (Claude Code)"
<versions-dir>/2.1.240 --version -> exit 0, "2.1.240 (Claude Code)"
<versions-dir>/2.1.241 --version -> exit 0, "2.1.241 (Claude Code)"
<versions-dir>/2.1.243 --version -> exit 139 (SIGSEGV)

(<versions-dir> is the native installer's per-user versions directory, the
default location; all four binaries sit side by side there.)

Working directory is irrelevant -- 2.1.243 was tried from the home directory,
from a local filesystem and from an NFS mount, and segfaults identically in
every case.

KERNEL LOG (three separate launches)
claude[163831]: segfault at 0 ip 0000000001d10458 sp 00007ffc29d05900 error 4 in 2.1.243[1b0f458,1953000+3b33000] likely on CPU 2
claude[163952]: segfault at 0 ip 0000000001d10458 sp 00007ffc7b80ed90 error 4 in 2.1.243[1b0f458,1953000+3b33000] likely on CPU 3
claude[163968]: segfault at 0 ip 0000000001d10458 sp 00007ffc512e7960 error 4 in 2.1.243[1b0f458,1953000+3b33000] likely on CPU 3

Notable: identical faulting instruction pointer (0x1d10458, module offset
0x1b0f458) every time, "segfault at 0" with error code 4 -- a user-mode read of
a null pointer. Deterministic null dereference during startup, not memory
corruption or a race.

POSSIBLY RELEVANT
The 2.1.243 binary is substantially larger than its predecessors, so this
release seems to carry a real build change rather than a patch:
342563120 2.1.239
342636848 2.1.240
342636848 2.1.241
377568472 2.1.243
ldd on the 2.1.243 binary reports no missing shared libraries.

Note on one theory worth ruling out: this machine runs CachyOS, which ships
aggressively optimized builds, so an instruction-set baseline mismatch is a
natural suspicion. It does not fit the evidence -- a too-new instruction
baseline raises SIGILL, not a null-pointer read at a fixed address.

ENVIRONMENT
OS: CachyOS (Arch-based)
Kernel: 7.2.0-1-cachyos, x86_64
glibc: 2.44
CPU: Intel Core i7-7700HQ (Kaby Lake; AVX2, no AVX-512)
Node: v26.7.0 (likely irrelevant -- the installed binary is a native ELF
executable, not a node script)
Install: native installer (per-user versions directory, symlinked onto PATH)
Terminal: xterm-256color

WORKAROUND
Repoint the launcher symlink at the last known-good version:
ln -sfn <versions-dir>/2.1.241 <bin-dir>/claude
Confirmed working. Note that an already-running session survives the bad
update, since it keeps executing the older binary from memory -- which masks
the problem until the next launch.

Environment Info

  • Platform: linux
  • Terminal: konsole
  • Version: 2.1.241
  • Feedback ID: 77d002ba-64af-4e69-a9de-94f6bde16cac

Errors

[]

View original on GitHub ↗

5 Comments

humb1t · 5 days ago

Same for me

CarlosSouza · 5 days ago

Confirming this on a different CPU generation, with the same faulting instruction pointer — plus the caller frames, which narrow the cause down.

Environment

  • CachyOS (Arch-based), kernel 7.1.8
  • Intel i7-10700K (Comet Lake) — the original report is Kaby Lake, so this is not microarchitecture-specific
  • glibc 2.44
  • Native installer layout (versions/ directory + launcher symlink)

Same crash

2.1.243 segfaults on every invocation, including --version. On the same machine 2.1.237, 2.1.238 and 2.1.241 all exit 0. The faulting IP matches this report exactly: 0x0000000001d10458.

The frames above the fault

coredumpctl info gives the caller chain, which shows this is not a bare null dereference in application code:

Stack trace of thread 34666:
#0  0x0000000001d10458 free (2.1.243 + 0x1b10458)
#1  0x00007ff08163a1ab __newlocale (libc.so.6 + 0x3a1ab)
#2  0x0000000001abd282 n/a (2.1.243 + 0x18bd282)
#3  0x00007ff0816b2584 n/a (libc.so.6 + 0xb2584)
#4  0x00007ff0816b26a9 pthread_once (libc.so.6 + 0xb26a9)
#5  0x0000000001abc2d2 n/a (2.1.243 + 0x18bc2d2)

glibc's __newlocale calls free, and that free resolves into the binary's own bundled allocator (2.1.243 + 0x1b10458) instead of glibc's. So: memory allocated by libc being released through a different allocator, during one-time locale initialisation under pthread_once.

That is consistent with the crash being fully deterministic and independent of the environment. In particular it is not locale-configuration dependent — LC_ALL=C claude --version crashes identically here, with the same IP.

Not a corrupted download

2.1.243 is 377568472 bytes here, and 2.1.241 is 342636848 — matching the size difference others have reported, so the larger binary is a real build change rather than a bad fetch.

Workaround and a caveat

Repointing the launcher symlink to 2.1.241 works. Worth flagging for anyone hitting this: the auto-updater points the symlink back at 2.1.243 on a later launch, so the crash returns without any new version being downloaded. Setting DISABLE_AUTOUPDATER=1 (or "env": { "DISABLE_AUTOUPDATER": "1" } in settings.json) holds the rollback in place until a build past 2.1.243 ships.

Heyian · 5 days ago

I suggest to simply use a custom launcher instead. Simply replace the launcher's symlink in ~/.local/bin/claude with a custom script, this way you'll keep getting updates and you'll be able to easily test those updates as they get in. Just make sure you flip it back to the symlink once the fix has arrived.

#!/bin/sh
PIN="${CLAUDE_PIN:-2.1.241}"
BIN="$HOME/.local/share/claude/versions/$PIN"
if [ ! -x "$BIN" ]; then
  echo "claude: pinned version $PIN not found in ~/.local/share/claude/versions" >&2
  exit 127
fi
exec "$BIN" "$@"
JackMcE · 2 days ago

FYI at this point in time what I found easier to do was...

  1. Take the script @Heyian made and save it as an sh file on my desktop.
  2. Run the script via terminal.
  3. Claude will launch and self install it's latest update which fixes this bug.
  4. Exit that instance of Claude.
  5. Run the claude command in terminal like usual.

The devs have fixed the bug but if you're still on a busted version you won't be able to claude normally into the application to get the automated update. The script will let you get in, let the client get the latest, and then you can exit out to use like normal without having to juggle symlinks.

draftcode · 2 days ago

FYI: Apparently fixed in 2.1.250