[Bug] Claude Code 2.1.243 crashes with SIGSEGV on startup (null pointer dereference)
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
- 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).
- Run
claude-- or evenclaude --version-- from any directory. - 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.243ldd 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
[]
5 Comments
Same for me
Confirming this on a different CPU generation, with the same faulting instruction pointer — plus the caller frames, which narrow the cause down.
Environment
versions/directory + launcher symlink)Same crash
2.1.243segfaults on every invocation, including--version. On the same machine2.1.237,2.1.238and2.1.241all exit 0. The faulting IP matches this report exactly:0x0000000001d10458.The frames above the fault
coredumpctl infogives the caller chain, which shows this is not a bare null dereference in application code:glibc's
__newlocalecallsfree, and thatfreeresolves 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 underpthread_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 --versioncrashes 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" }insettings.json) holds the rollback in place until a build past 2.1.243 ships.I suggest to simply use a custom launcher instead. Simply replace the launcher's symlink in
~/.local/bin/claudewith 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.FYI at this point in time what I found easier to do was...
claudecommand 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
claudenormally 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.FYI: Apparently fixed in 2.1.250