SIGILL panic at identical binary offset chain (+0x2905212) across v2.1.168–v2.1.170 on one Linux machine; identical sibling machines unaffected

Summary

Claude Code (native installer, Linux x86_64) repeatedly crashes with SIGILL on one specific machine — 5 coredumps in 4 days across v2.1.168, v2.1.169, and v2.1.170. The crashing thread faults at the byte-identical binary offset chain across all three versions, and the faulting frames sit above __restore_rt, i.e. the illegal instruction executes inside a signal handler — this looks like the runtime's own fault/panic handler hitting a deliberate trap (ud2) after intercepting an underlying fault.

Two sibling machines with the same OS image, same kernel, same glibc, and same Claude Code versions have zero crashes ever (verified via coredumpctl, on-disk coredump directory, and full journal sweep) — including one that processed a multi-million-token session (13 novels read line-by-line in a single session) the same week without issue. So this is not load- or context-size-related; it is machine- or workload-path-specific.

Environment

Affected machine:

• Linux Mint 22.3 (Zena), kernel 6.17.0-35-generic, glibc 2.39 (Ubuntu 24.04 base)
• CPU: Intel i9-12900K (Alder Lake), 62 GB RAM (no OOM events; plenty of free memory at crash time)
• Claude Code native installer, launched from GNOME Terminal (vte)
• Crashes occur mid-session during normal interactive use, never at launch

**Unaffected control machines (zero crashes, thoroughly verified — coredumpctl, on-disk coredump dir, and indexed journal query for systemd-coredump records all empty; the 14900KF box has never recorded a coredump from any process):**

• Same Linux Mint 22.3 / kernel 6.17.0-35 / glibc 2.39, CPU i9-14900KF — Claude Code 2.1.172
• Same Linux Mint 22.3 / kernel 6.17.0-35 / glibc 2.39, CPU i7-6820HQ (Skylake) — Claude Code 2.1.173

All three machines run the same project/MCP configuration.

Crash history (systemd-coredump)

| Date (EDT) | Version | Signal | Crashing-thread frame #0 |
|---|---|---|---|
| 2026-06-08 13:14 | 2.1.168 | SIGILL | +0x338497a |
| 2026-06-09 19:06 | 2.1.168 | SIGILL | +0x2905212 |
| 2026-06-09 19:56 | 2.1.169 | SIGILL | +0x2905212 |
| 2026-06-11 06:29 | 2.1.170 | SIGILL | +0x2905212 |
| 2026-06-11 06:32 | 2.1.170 | SIGILL | +0x2905212 |

Earlier versions on the same machine also crashed (SIGILL on 2.1.156/2.1.158/2.1.161, SIGABRT on 2.1.159), so this has persisted across many releases. No crashes observed yet on 2.1.173 (just updated).

Crashing-thread backtrace (identical offsets across 2.1.168 / 2.1.169 / 2.1.170)

Stack trace of thread <crashing>:
#0  binary + 0x2905212   <- SIGILL here
#1  binary + 0x273d8ba
#2  binary + 0x267aa08
#3  binary + 0x4a21f0d
#4  __restore_rt (libc.so.6 + 0x45330)   <- frames 0-3 run inside a signal handler
#5  binary + 0x534a7xx / 0x58245ac (varies slightly per dump)
#6  binary + 0x534a3d6
...

Most recent full dump (v2.1.170, PID 439768), other notable thread:

Stack trace of thread 439878:
#0  binary + 0x4b24866
#1  binary + 0x534a7b7
#2  binary + 0x534a3d6
#3  binary + 0x534b37d
#4  binary + 0x5310b00
#5  binary + 0x533989f
#6  binary + 0x533a174
#7  binary + 0x4a22ee3
#8  start_thread (libc.so.6 + 0x9caa4)
#9  __clone3 (libc.so.6 + 0x129c6c)

Notes

• The deterministic offset chain across three releases suggests the relevant code region (likely the bundled runtime's fault/crash handler) is stable between builds — symbolication of +0x2905212/+0x273d8ba/+0x267aa08/+0x4a21f0d against your symbol files should identify it immediately.
• Coredumps (~80–92 MB each, zstd) are retained and available on request; happy to run gdb commands against them or test diagnostic builds/env flags.
• Hardware on the affected machine is otherwise stable (heavy daily .NET builds, GPU workloads, no other process crashes in the journal).