[BUG] Recurring mid-session SIGSEGV of native linux-x64 binary across 2.1.210-2.1.278 (Bun 1.4.3, glibc 2.42) - distinct from the glibc 2.44 startup cluster

Summary

The native linux-x64 binary SIGSEGVs mid-session, not at startup, and has done so repeatedly across nine releases over the last two months. This appears distinct from the large cluster of startup-segfault reports (#89370, #89412, #89415, #89504, #89732, #89759, #92749, #94462), which are tied to glibc 2.44 / Arch and fault inside __newlocale during init. This machine runs glibc 2.42, startup is reliable, and the crash lands after a long, healthy session.

Environment

Crash history

systemd-coredump has recorded six SIGSEGVs of the claude binary on this machine:

So this is not a regression introduced by one release — it spans 2.1.210 through 2.1.278 and at least three different bundled Bun versions.

Evidence that it is not a startup crash

For the 2026-09-20 crash (PID 365693):

• The session transcript's first entry is 2026-09-20T08:28:52Z; its last entry is 2026-09-20T09:54:48Z. The core was dumped at 09:56:21Z — roughly 1 h 27 min into the session, and ~93 s after the last recorded activity.
• The thread list in the core shows two distinct generations of thread IDs: the startup threads (365697–365811, contemporaneous with the main thread's PID 365693) and a much later generation (509729, 509731, 509733, 509755, 510082) created once the system PID counter had advanced by ~144 000. Those later threads are all parked in pthread_cond_timedwait.
• The transcript's final line is structurally complete, so the process was not killed mid-write; it faulted while idle or between operations.

Faulting thread

Binary is stripped, so only offsets are available. The shape is a fault handler re-raising: __restore_rt at #6 means frames #7 and above are the original fault, and frames #12–#14 are the same address repeated, which suggests a recursive path.

Stack trace of thread 365693:
#0  0x00007f5f78068c6c __pthread_kill_implementation (libc.so.6 + 0x92c6c)
#1  0x00007f5f78011da6 raise (libc.so.6 + 0x3bda6)
#2  0x00000000037c88b2 n/a (claude 2.1.278 + 0x35c88b2)
#3  0x00000000037c7c9d n/a (claude 2.1.278 + 0x35c7c9d)
#4  0x00000000037c8664 n/a (claude 2.1.278 + 0x35c8664)
#5  0x0000000003b2ecdc n/a (claude 2.1.278 + 0x392ecdc)
#6  0x00007f5f78011ef0 __restore_rt (libc.so.6 + 0x3bef0)     <-- signal boundary
#7  0x0000000004beb15d n/a (claude 2.1.278 + 0x49eb15d)       <-- fault site
#8  0x0000000003b8cfe6 n/a (claude 2.1.278 + 0x398cfe6)
#9  0x0000000004ebcf5f n/a (claude 2.1.278 + 0x4cbcf5f)
#10 0x00000000046e5acb n/a (claude 2.1.278 + 0x44e5acb)
#11 0x00007f5f73c8c017 n/a (n/a + 0x0)                        <-- JIT frame
#12 0x0000000003cbfc55 n/a (claude 2.1.278 + 0x3abfc55)
#13 0x0000000003cbfc55 n/a (claude 2.1.278 + 0x3abfc55)
#14 0x0000000003cbfc55 n/a (claude 2.1.278 + 0x3abfc55)
#15 0x0000000003c9fcc4 n/a (claude 2.1.278 + 0x3a9fcc4)
#16 0x0000000004b693c9 n/a (claude 2.1.278 + 0x49693c9)
#17 0x0000000004b64908 n/a (claude 2.1.278 + 0x4964908)
#18 0x0000000004e2865e n/a (claude 2.1.278 + 0x4c2865e)
#19 0x0000000004f83494 n/a (claude 2.1.278 + 0x4d83494)
#20 0x000000000233c79d n/a (claude 2.1.278 + 0x213c79d)
#21 0x00007f5f740d6f1a n/a (n/a + 0x0)                        <-- JIT frame
#22 0x00007f5f740d6f41 n/a (n/a + 0x0)                        <-- JIT frame
#23 0x0000000003c9fcc4 n/a (claude 2.1.278 + 0x3a9fcc4)
#24 0x00000000046287f7 n/a (claude 2.1.278 + 0x44287f7)
#25 0x000000000497f433 n/a (claude 2.1.278 + 0x477f433)
#26 0x000000000226af80 n/a (claude 2.1.278 + 0x206af80)
#27 0x00000000022b7d26 n/a (claude 2.1.278 + 0x20b7d26)
#28 0x0000000002fd5933 n/a (claude 2.1.278 + 0x2dd5933)
#29 0x000000000213df88 n/a (claude 2.1.278 + 0x1f3df88)
#30 0x0000000002fd5bd7 n/a (claude 2.1.278 + 0x2dd5bd7)
#31 0x0000000001d84226 n/a (claude 2.1.278 + 0x1b84226)
#32 0x0000000002047b06 n/a (claude 2.1.278 + 0x1e47b06)
#33 0x000000000204289b n/a (claude 2.1.278 + 0x1e4289b)
#34 0x000000000214258c n/a (claude 2.1.278 + 0x1f4258c)
#35 0x00007f5f77ffc2f9 __libc_start_call_main (libc.so.6 + 0x262f9)
#36 0x00007f5f77ffc3ab __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x263ab)
#37 0x0000000001922c2e n/a (claude 2.1.278 + 0x1722c2e)

Reproduction

No deterministic trigger identified. Ordinary interactive use; crashes recur every week or two.

What would help

1. Shipping symbols, or a .debug sidecar / build ID, so offsets like +0x49eb15d can be resolved. As it stands, every Linux crash report is just offsets and no one can act on them. The binary does carry BuildID[sha1]=83effae1a76aa74ce70326f83068a1242f99094a, but there is nothing public to match it against.
2. I still have the 98.5 MB core for the 2026-09-20 crash and am happy to run any requested gdb commands against it, or send it privately. Earlier cores have been rotated away, so it will not last indefinitely.

Note on the workaround question

There is currently no way to run Claude Code off the Bun runtime. The npm package @anthropic-ai/claude-code is a 184 KB wrapper whose optionalDependencies fetch the same 234 MB native binary (@anthropic-ai/claude-code-linux-x64); its engines: node >=22 only governs the postinstall script. So for users hitting Bun-runtime faults there is no Node-based fallback to switch to. A supported way to run under Node would be a genuine mitigation for this whole class of report.

No source file or test is named, and no deterministic trigger is identified. Start with the retained 98.5 MB core in gdb and the requested symbols or build ID to resolve offsets such as +0x49eb15d; done means identifying the mid-session fault and an actionable fix or documented mitigation.