[BUG] Recurring Bun-runtime SIGABRT/SIGSEGV crashes across Claude Code 2.1.231-2.1.243 on Linux ARM64 (glibc 2.34) — clustered multi-process crashes, corrupted stack frame evidence

Preflight Checklist

• [x] Searched existing issues (found #60215, now closed/stale, same crash family on x86_64/Ubuntu)
• [x] Single bug report
• [x] Using a recent version of Claude Code (currently 2.1.243; crashes recorded across 2.1.231–2.1.241 as well)

What's Wrong?

Bug: Recurring Bun-runtime Aborted (core dumped) / segfault crashes across many Claude Code point releases on Linux ARM64 (aarch64)

Claude Code sessions on this host crash unpredictably — mostly mid-session, not on startup — with the native Bun-compiled binary aborting or segfaulting. systemd-coredump has recorded 122 crash events across 10 distinct point releases (2.1.231 through 2.1.241) since 2026-08-12, and it is still happening on the current version (2.1.243). This looks like the same underlying crash family reported in #60215 (Bun runtime segfault, "Illegal instruction (core dumped)", non-deterministic, mid/long-session), but:

• it has persisted across many releases since that report (not fixed by any point release in between),
• it reproduces on Linux ARM64, not just the x86_64 platform in #60215,
• and I have a captured backtrace showing what looks like stack corruption, not a simple null pointer deref — worth flagging in case it's a different root cause than the currently-active glibc-2.44 newlocale/free-interposition segfault cluster (e.g. #89334, #89536) that's unrelated to this glibc version.

This is NOT the glibc 2.44 startup-segfault regression — this host's glibc is 2.34 (Amazon Linux 2023), and the crashes here are mid-session SIGABRT/SIGSEGV, not an immediate segfault on claude --version or first launch.

Environment

• Claude Code: 2.1.243 (current); crashes also recorded on 2.1.231, 2.1.232, 2.1.233, 2.1.234, 2.1.235, 2.1.236, 2.1.237, 2.1.241
• Bun (bundled, current binary): v1.4.0 (19bc277a0) Linux arm64
• OS: Amazon Linux 2023 (ID=amzn, VERSION_ID=2023)
• Kernel: 6.18.35-68.127.amzn2023.aarch64
• Arch: aarch64
• glibc: 2.34
• Host has not rebooted since 2026-08-13 — the crash clusters below are not reboot-correlated, and no OOM-killer entries appear in the journal around any of the crash timestamps.

Crash statistics (from coredumpctl + journalctl, this host only)

• 122 claude-binary coredump entries recorded by systemd-coredump between 2026-08-12 and 2026-08-25.
• Signal breakdown: 119 × SIGABRT, 3 × SIGSEGV.
• Distinct crash dates: 2026-08-12, 2026-08-18, 2026-08-19, 2026-08-20, 2026-08-25.
• Crashes frequently arrive in tight clusters — e.g. on 2026-08-25 at 01:57:53 UTC, 15 separate claude processes (spanning versions 2.1.236 and 2.1.241 concurrently) all terminated with SIGABRT within the same second. Similar multi-process clusters recur on 08-19 and 08-20. Most of these report "terminated abnormally without generating a coredump" (likely RLIMIT_CORE/coredump-collection related), so a full core wasn't always captured.

Captured backtrace (one case where a full core was written)

2.1.237, PID 909422, 2026-08-20 14:49:11 UTC, SIGABRT, dumped core:

Stack trace of thread 909422:
#0  0x00000000018aa2e0 n/a (.../claude/versions/2.1.237 + 0x16aa2e0)
#1  0x00000000018aa23c n/a (.../claude/versions/2.1.237 + 0x16aa23c)
#2  0x00000000018aa23c n/a (.../claude/versions/2.1.237 + 0x16aa23c)   <- identical to #1
#3  0x0000000001881518 n/a (.../claude/versions/2.1.237 + 0x1681518)
#4  0x0000000001895cb0 n/a (.../claude/versions/2.1.237 + 0x1695cb0)
#5  0x0000000001893aac n/a (.../claude/versions/2.1.237 + 0x1693aac)
#6  0x0000000001889b80 n/a (.../claude/versions/2.1.237 + 0x1689b80)
#7  0x00000000018818b8 n/a (.../claude/versions/2.1.237 + 0x16818b8)
#8  0x00000000019a8ccc n/a (.../claude/versions/2.1.237 + 0x17a8ccc)
#9  0x00000000019a9014 n/a (.../claude/versions/2.1.237 + 0x17a9014)
#10 0x0000ffffab6cb558 __libc_start_call_main (libc.so.6 + 0x30558)
#11 0x0000ffffd8ab3b61 n/a (n/a + 0x0)
#12 0x0000ffffd8ab3b61 n/a (n/a + 0x0)               <- identical to #11
#13 0x72656b636f443d65 n/a (n/a + 0x0)
ELF object binary architecture: AARCH64

Two things stand out:

1. Frames #1/#2 (and #11/#12) are identical addresses — consistent with either a self-referential/corrupted return address or an unwinder walking into a repeating memory pattern.
2. Frame #13's "address" (0x72656b636f443d65) decodes as the ASCII string "e=Docker" when read as bytes. That is not a plausible return address — it's a fragment of environment-variable text. The stack unwinder is reading environment/argv memory as if it were the call stack, which strongly suggests actual stack corruption (e.g. a buffer overflow, a misdirected pointer, or the frame pointer chain running off the end of the real stack into adjacent process memory) rather than a straightforward null-pointer segfault.

I don't have symbols for the bundled binary so I can't map the offsets to source, but I can provide the raw .coredump file (still present on disk) if that's useful — let me know.

Steps to Reproduce

No reliable minimal repro — same as #60215, it happens unpredictably during normal interactive/long-running sessions (including unattended background-agent sessions), with no specific tool call, MCP server, or slash command consistently preceding it. Given it also happens on several different point releases concurrently, it doesn't look tied to one specific code change either — more likely a latent memory-safety issue in the bundled Bun runtime (or its interaction with mimalloc/glibc on aarch64) that gets triggered under sustained/heavy session load.

What Should Happen?

Claude Code (and the bundled Bun runtime) should not abort/segfault during normal use, regardless of session length or platform.

Asks

1. Is this the same root cause as #60215, or a distinct ARM64-specific issue? It clearly wasn't fixed by any of the ~10 point releases between 2.1.231 and 2.1.243.
2. Is there a way to get symbolized backtraces from the bundled Bun binary for future crashes (it currently unwinds to raw offsets with n/a symbols)?
3. Any known-good version for Linux ARM64 users experiencing this, similar to what was suggested in #60215 for x86_64?

Claude Code Version

2.1.243 (also reproduced on 2.1.231, 2.1.232, 2.1.233, 2.1.234, 2.1.235, 2.1.236, 2.1.237, 2.1.241)

Platform

Anthropic API (Bedrock-backed)

Operating System

Amazon Linux 2023, aarch64 (kernel 6.18.35)

Is this a regression?

Unclear — the crash family predates 2.1.231 per #60215, and has persisted through every subsequent release checked here.