›_ Claude Code Issues
Claude Code Issues / #62747

[BUG] Immediate segmentation fault upon starting - claude (Bun runtime) segfaults at startup on Linux 6.17 / glibc 2.39 — all builds since Node→Bun switch

Status Fixed / completed
Reported on v2.1.139
Maintainer reply None cached
Activity 8 comments · opened May 27, 2026 · closed Jul 1, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

I am NOT using the latest version because anything after 2.1.139 immediately segfaults.

Start any version 2.1.140 or above and immediate segmentation fault. Can't event run --version as it crashes out before getting as far as printing anything.

What Should Happen?

Claude code should start normally.

Error Messages/Logs

Starting any version after 2.1.139 (this is 2.2.146) immediately seg faults.

$ strace claude
brk(NULL) = 0x1f52b000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7072abad8000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=93303, ...}) = 0
mmap(NULL, 93303, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7072abac1000
close(3) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14624, ...}) = 0
mmap(NULL, 16400, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7072ababc000
mmap(0x7072ababd000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7072ababd000
mmap(0x7072ababe000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7072ababe000
mmap(0x7072ababf000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7072ababf000
close(3) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\243\2\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
fstat(3, {st_mode=S_IFREG|0755, st_size=2125328, ...}) = 0
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
mmap(NULL, 2170256, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7072ab800000
mmap(0x7072ab828000, 1605632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x28000) = 0x7072ab828000
mmap(0x7072ab9b0000, 323584, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b0000) = 0x7072ab9b0000
mmap(0x7072ab9ff000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1fe000) = 0x7072ab9ff000
mmap(0x7072aba05000, 52624, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7072aba05000
close(3) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14408, ...}) = 0
mmap(NULL, 16400, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7072abab7000
mmap(0x7072abab8000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7072abab8000
mmap(0x7072abab9000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7072abab9000
mmap(0x7072ababa000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7072ababa000
close(3) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14408, ...}) = 0
mmap(NULL, 16400, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7072abab2000
mmap(0x7072abab3000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7072abab3000
mmap(0x7072abab4000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7072abab4000
mmap(0x7072abab5000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7072abab5000
close(3) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=952616, ...}) = 0
mmap(NULL, 950296, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7072ab717000
mmap(0x7072ab727000, 520192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10000) = 0x7072ab727000
mmap(0x7072ab7a6000, 360448, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8f000) = 0x7072ab7a6000
mmap(0x7072ab7fe000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe7000) = 0x7072ab7fe000
close(3) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7072abab0000
mmap(NULL, 73728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7072aba9e000
arch_prctl(ARCH_SET_FS, 0x7072abaae580) = 0
set_tid_address(0x7072abaae850) = 31937
set_robust_list(0x7072abaae860, 24) = 0
rseq(0x7072abaaeea0, 0x20, 0, 0x53053053) = 0
mprotect(0x7072ab9ff000, 16384, PROT_READ) = 0
mprotect(0x7072ab7fe000, 4096, PROT_READ) = 0
mprotect(0x7072abab5000, 4096, PROT_READ) = 0
mprotect(0x7072ababa000, 4096, PROT_READ) = 0
mprotect(0x7072ababf000, 4096, PROT_READ) = 0
mprotect(0x7072abb18000, 8192, PROT_READ) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
munmap(0x7072abac1000, 93303) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
+++ killed by SIGSEGV (core dumped) +++

Steps to Reproduce

Install claude code 2.1.146
Execute "claude"
Segmentation fault

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.139

Claude Code Version

2.1.146

Platform

AWS Bedrock

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Xterm

Additional Information

$ /home/johnsargent/.local/share/claude/versions/2.1.146 
Segmentation fault (core dumped)

✗ 139 ~ $ cat .claude/settings.json 
{
  "autoUpdaterStatus": "disabled",
  "env": {
    "DISABLE_AUTOUPDATER": "1",
    "DISABLE_AUTOUPDATES": "1",
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "ANTHROPIC_MODEL": "opus",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "global.anthropic.claude-opus-4-7",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "global.anthropic.claude-sonnet-4-5-20250929-v1:0",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "global.anthropic.claude-haiku-4-5-20251001-v1:0",
    "DISABLE_PROMPT_CACHING": "0"
  }
}

Tried removing the .claude directory so I get clean settings etc. - no difference, still segfault.

Tried with every version after 2.1.139 as it appeared but they all crash out in the same way, so I assume something was introduced in 2.1.140 that caused the issue and that persists

Would attach the core file, but it obviously contains API keys and the like, so I can't.

This is on Ubuntu 24.04 - this is NOT a duplicate of all the Windows segmentation fault issues for different versions or after running certain operations. This doesn't even get as far as fully loading.

View original on GitHub ↗

8 Comments

github-actions[bot] · 3 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/61530
  2. https://github.com/anthropics/claude-code/issues/61356
  3. https://github.com/anthropics/claude-code/issues/60307

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

johnsargent-sophos · 3 months ago

This is not a duplicate of any of those. Similar symptoms, but different environment. This is for ANY version after 2.1.139 not just 2.1.148 or 2.1.145 as in the other tickets

johnsargent-sophos · 2 months ago

I asked claude 2.1.139 to diagnose why anything > 2.1.139 crashes out... this is what it came up with

● I've worked it out. Here's the conclusion.

Root cause

Every build newer than your 2.1.139 uses a rebuilt Node host that segfaults during V8 startup on this machine — before any Claude code runs. It's an incompatibility in the bundled runtime, not in Claude's JS, and not file corruption.

The evidence chain:

  • It's the runtime, not Claude. strace shows SIGSEGV with si_code=SI_KERNEL, si_addr=NULL immediately after the loader maps libc/libm, before the program makes a single syscall of its own. gdb pins it at call *%rax — the first indirect call of Node/V8 bootstrap.
  • The bad build is shared across all newer versions. 2.1.145, 2.1.146, and the VS Code extension's 2.1.160 all carry the identical BuildID 2eabd56b… and all segfault identically (exit 139). Your working 2.1.139 has a different BuildID (b814cadd…) — a different, older Node host — and runs fine

(exit 0). So the breakage was introduced when the Node host was rebuilt for the 2.1.14x line and has carried forward since.

  • It's not corruption / not your hand-edited install. ELF section table is valid, all LOAD segments fit, the Node SEA payload trailer is intact, and the extension's 2.1.160 (a pristine file with a different content hash but the same Node-host BuildID) crashes the same way. Three

independently-delivered files, same crash → it's the host build, not a bad download.

  • The exact fault: the code checks two feature flags, loads a function pointer from a GOT slot that has no loader relocation (0x629d110, written at runtime during Node init), confirms it's non-null, and calls it — but the address is garbage. A runtime-initialized dispatch pointer that this

newer Node build sets up incorrectly in your environment (kernel 6.17 / glibc 2.39).

  • Not fixable via flags: --no-snapshot, --jitless, --single-threaded, and disabling ASLR all still crash, because the fault happens before NODE_OPTIONS is parsed.

Bottom line

Your 2.1.139 works because it predates the Node-host rebuild. Everything after it ships the 2eabd56b host that can't initialize V8 here. That's exactly why you keep it pinned/immutable — and why "updating" always re-breaks you.

johnsargent-sophos · 2 months ago

Digging a bit deeper with gdb, the crash is in the Bun runtime - you get SIGSEGV during Bun runtime init, before main/arg parsing. Faulting insn: call *%rax at .text 0x3fa8a30, with rax loaded from data-segment global 0x629d110. That global is never initialized to a valid pointer — at crash it contains embedded-JS-payload bytes (0x7b2972572c72592c = ASCII ",Yr,Wr){"), identical on disk and stable across runs (not heap corruption / not ASLR). i.e. an uninitialized function-pointer global in the bundled Bun/JavaScriptCore host is called through during startup. Pre-Bun build 2.1.139 (BuildID b814cadd…) works; all post-switch builds (BuildID 2eabd56b…: 2.1.145/146/160) crash identically.

## Summary

Every claude build since the runtime switched from Node to Bun segfaults
immediately on any invocation (e.g. claude --version), exit code 139,
before executing any JS. The last working build is 2.1.139 (pre-Bun). 2.1.145,
2.1.146, and the VS Code extension's bundled 2.1.160 — all sharing Bun-host
BuildID 2eabd56b93310e766961206f003fc2e163ec5f86 — crash identically.

## Environment

  • OS: Linux 6.17.0-35-generic (Ubuntu)
  • glibc: 2.39 (Ubuntu GLIBC 2.39-0ubuntu8.7)
  • CPU flags: avx, avx2, bmi1, bmi2, fma, sse4_1, sse4_2
  • vm.overcommit_memory=0, vm.max_map_count=1048576
  • transparent_hugepage: tested both always and madvise (no difference)
  • Install method: native

## Affected builds

  • WORKS: 2.1.139, BuildID b814cadd7d52598469a16ff588bb336ff6bcb37f (pre-Bun, Node host)
  • CRASHES: 2.1.145 / 2.1.146 / 2.1.160, BuildID 2eabd56b93310e766961206f003fc2e163ec5f86 (Bun host)
  • 2.1.146 build: GIT_SHA c900a8c71aa966a1a8bf14c49139d87fac9ae881, BUILD_TIME 2026-05-20T01:47:26Z

SIGSEGV (si_code=SI_KERNEL, si_addr=NULL) during Bun/JavaScriptCore runtime
init, before main/argument parsing — strace shows the crash right after the
dynamic loader maps libc/libm and sets up TLS, before the program makes a single
syscall of its own.

Faulting instruction: call *%rax at .text address 0x3fa8a30. rax is
loaded from data-segment global 0x629d110. That global is never initialized to
a valid pointer — at the crash it contains embedded-JS-payload bytes
0x7b2972572c72592c (ASCII ,Yr,Wr){). The value is identical on disk and
stable across runs, so this is not heap corruption and not ASLR-related.
In effect, an uninitialized function-pointer global in the bundled Bun host is
called through during startup.

Program received signal SIGSEGV, Segmentation fault.
0x0000000003fa8a30 in ?? ()
=> 0x3fa8a30: ff d0 call *%rax # rax = 0x7b2972572c72592c (not a code address)
#0 0x0000000003fa8a30
#1 0x0000000000000000

The crash precedes option parsing, so no runtime flag can affect it.

This looks like a Bun-host init regression specific to recent Linux kernel / glibc combinations.

johnsargent-sophos · 2 months ago

This seems to have been fixed in 2.1.197

nic116seitz · 6 days ago

Also hitting this on Arch Linux with an even newer glibc than the other reports here — wanted to add a data point since it's not fixed on the latest available glibc.

Environment:

  • Distro: Arch Linux (rolling release)
  • glibc: 2.44 (ldd (GNU libc) 2.44)
  • Claude Code versions tested: 2.1.243 (native installer) and 2.1.243 / 2.1.205 (via npm) — all segfault identically
  • Both the native binary install and the npm-based install segfault, since npm's postinstall pulls the same Bun-compiled binary

Reproduction: Segfaults on every invocation, including claude doctor — not specific to any subcommand.

Backtrace (via coredumpctl gdb claude, bt):

#0  0x0000000001d10458 in free ()
#1  0x00007fcf3423530a in __newlocale (category_mask=<optimized out>, locale=<optimized out>,
    base=<optimized out>) at newlocale.c:291
#2  0x0000000001abd282 in ?? ()
#3  0x00007fcf3429d7fc in __pthread_once_slow (once_control=0x54deb1c, init_routine=0x1abc1d0)
    at pthread_once.c:116
#4  0x00007fcf3429d879 in ___pthread_once (once_control=<optimized out>, init_routine=<optimized out>)
    at pthread_once.c:143
#5  0x0000000001abc2d2 in ?? ()
#6  0x0000000001ace6cf in ?? ()
#7  0x0000000001abdc0a in ?? ()
#8  0x0000000001abe9c4 in ?? ()
#9  0x00007fcf3429d7fc in __pthread_once_slow (once_control=0x54deb28, init_routine=0x1abe990)
    at pthread_once.c:116
#10 0x00007fcf3429d879 in ___pthread_once (once_control=<optimized out>, init_routine=<optimized out>)
    at pthread_once.c:143
#11 0x0000000001abea15 in ?? ()
#12 0x0000000001abead7 in ?? ()
#13 0x0000000001abb922 in ?? ()
#14 0x0000000001abb724 in ?? ()
#15 0x0000000001aadadd in ?? ()
#16 0x00007fcf34227892 in __libc_start_main_impl (main=0x1b1b550, argc=1, argv=0x7fff75dfed58, init=0x1aada90,
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff75dfed48) at ../csu/libc-start.c:355
#17 0x0000000001953a2e in ?? ()

Things I've ruled out:

  • Not a locale env var issue — LANG=C.UTF-8 and LC_ALL=C.UTF-8 explicitly set, still segfaults
  • Not fixed by downgrading to 2.1.205 — same crash

Given LANG/LC_ALL being correctly set didn't help and an older version also fails, this looks like a genuine ABI incompatibility between the bundled Bun runtime and newer glibc rather than a locale-config issue specifically. Happy to test any candidate fix/build.

RobertRGreen · 6 days ago

Confirming and narrowing this on a different environment — Arch Linux (rolling release), kernel 7.1.9-arch1-2, glibc 2.44, Intel i5-11260H (full AVX2/AVX-512 support, so this isn't the separate CPU-feature crash reported elsewhere in this thread).

I bisected the exact regression boundary by installing each version via npm and running claude --version:

  • ✅ 2.1.212 — works
  • ✅ 2.1.228 — works
  • ✅ 2.1.235 — works
  • ✅ 2.1.239 — works
  • ✅ 2.1.241 — works
  • ❌ 2.1.242 — segfaults immediately, claude --version never prints
  • ❌ 2.1.243 (latest at time of testing) — same segfault

So on this system specifically, the regression was introduced between 2.1.241 and 2.1.242, not at 2.1.140 as originally reported — the crash may have been intermittently "fixed" and reintroduced, or this could be a distinct regression with the same symptom (immediate SIGSEGV, claude --version never completes). Happy to test any specific commit/build if that helps narrow further.

twistedrisers · 4 days ago

Title: Segfault on startup persists in 2.1.246 (Bun runtime, SIGSEGV at si_addr=NULL) — regression of #62747

Body:

Same failure mode as #62747, recurring in a much newer build.

Claude Code version (broken): 2.1.246
Last known working version: 2.1.235
OS: Arch Linux
Kernel: 7.1.9-arch1-2
glibc: 2.44
Arch: x86_64

claude --version segfaults immediately, before any output.

dmesg:
claude[903906]: segfault at 0 ip 0000000001d10458 sp 00007ffe7cffc960 error 4 in claude.exe[1b0f458,1953000+3b33000] likely on CPU 5 (core 5, socket 0)
strace tail:
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
+++ killed by SIGSEGV (core dumped) +++

Ruled out: /tmp noexec, ASLR, vm.overcommit_memory, ulimits, environment variables, transparent hugepages (tried madvise). Binary itself is a valid, non-truncated x86_64 ELF (verified with file). Installing 2.1.235 instead resolves it completely — claude --version and normal startup both work.

Given kernel 7.1.9 is very recent, this looks like the same Bun-runtime/kernel-compatibility class of bug as #62747, #76241, and #27699, possibly reintroduced or never fully fixed for newer kernels.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Installation & update problems, Crashes, hangs & freezes

Browse all Claude Code issue topics →