Claude CodeがLinux ARM64で繰り返しクラッシュする原因と切り分け

Claude CodeがLinux ARM64で、起動はできるのにセッションの途中でAborted (core dumped)と表示されて落ちる。この症状はGitHub issue #89539に報告されています。環境はAmazon Linux 2023(aarch64、glibc 2.34)です。報告はopenのままで、原因は特定されていません。

この記事では、報告の中身と、自分の環境で同じ症状か判断するための証拠の集め方を扱います。確実な回避策はまだありません。ただ、クラッシュの種類を切り分け、systemd-coredumpで記録を残す手順は今日から使えます。

起動時の即死とは別物のクラッシュ

LinuxでClaude Codeが落ちる報告は、大きく2種類あります。見分けないと、対処を取り違えます。

起動直後に必ず落ちるなら、Claude CodeがSIGSEGVで起動直後にクラッシュする原因と対処法の症状です。glibc 2.44環境のこの不具合は、v2.1.245で直っています。経緯はClaude Code v2.1.245のリリースノートにあります。

#89539の報告者も、自分のホストはその件ではないと明記しています。glibcは2.34で、落ちるのはclaude --versionや初回起動ではなく、使っている最中だからです。

報告されている症状と数字

報告は、coredumpctlとjournalctlから集めた同一ホストの記録です。

環境は次のとおりです。

• Claude Code 2.1.243(2.1.231〜2.1.237、2.1.241でも記録あり)
• 同梱のBun v1.4.0(Linux arm64)
• Amazon Linux 2023、カーネル6.18.35、aarch64
• glibc 2.34

報告者は、クラッシュは再起動とは連動せず、OOM killerの記録も無いと書いています。記録のある日付は8月12日、18日、19日、20日、25日です。

もう1つの特徴が、まとまって落ちることです。8月25日の01:57:53 UTCには、バージョン2.1.236と2.1.241の15個のclaudeプロセスが同じ秒にSIGABRTで終了しています。同様の群発が19日と20日にもありました。

コメントでは別の報告者が、クラッシュ群発の時点でホスト上にclaude関連プロセスが69個あったと書いています。バックグラウンドの待機用デーモンと、plan権限モードのセッションが並んでいました。メモリは126GBのうち71GBが空き、スワップ使用は0で、負荷も平均1.3〜2.8(16コア)です。多数のBunプロセスが同居する環境が引き金になっている、という見立てです。ただしこれは報告者の推測で、確認された原因ではありません。

バックトレースが示す、スタック破損の疑い

報告には、コアが書き出された1件(2.1.237、2026-08-20 14:49:11 UTC、SIGABRT)のスタックトレースが載っています。シンボルが無く、実行ファイル内のオフセットだけが並ぶ形です。

報告者が注目した点は2つです。

1. フレーム#1と#2、#11と#12が同じアドレスになっている。
2. フレーム#13のアドレス0x72656b636f443d65をバイト列として読むと、ASCIIでe=Dockerになる。環境変数の文字列の断片です。

2つめは、スタックを辿る処理(アンワインダー)が、環境変数や引数の領域を呼び出し履歴として読んでいることを意味します。報告者はここから、単純なヌルポインタ参照ではなくスタック破損の可能性を挙げています。ただ、ソースにシンボルを対応させられないため、原因までは断定していません。

issueの本文にはこうあります。同梱のBunや、アロケータ(mimalloc)とglibcのaarch64での相互作用に潜むメモリ安全性の問題が、負荷の高い状態で顔を出すのではないか、と。これも仮説です。

自分の環境で同じ症状かを調べる

最初に、自分の環境がどちらの症状に近いかを確かめます。

uname -m
ldd --version | head -1
claude --version

aarch64とglibc 2.34の組み合わせなら、報告と同じ条件です。glibcが2.44系なら、起動直後のSIGSEGVの記事を先に見てください。

次に、クラッシュが記録されているかをcoredumpctlで見ます。systemd-coredumpが有効なホストなら、保存されたコアとメタデータを取り出せます。

# 直近のclaudeのクラッシュを新しい順に
coredumpctl list claude -r -n 20
 
# 日付で絞る
coredumpctl list claude --since "2026-08-01"
 
# シグナル別の件数
coredumpctl list claude --no-legend | grep -c SIGABRT
coredumpctl list claude --no-legend | grep -c SIGSEGV

coredumpctl listのCOREFILE列は、コアが保存されたかを示します。noneは保存されていない、presentは読める状態で残っている、missingは保存後に消えた、という意味です。クラッシュの件数と、コアが実際に残った件数を分けて見てください。報告でも、多くの終了は「コアを生成せずに異常終了した」と記録されています。

1件の詳細はinfoで見ます。PIDはlistの出力から拾います。

coredumpctl info 909422

シグナル、実行ファイル、タイムスタンプ、保存されたコアの有無に加え、コアがあればスタックトレースも表示されます。報告者が貼ったバックトレースは、この出力に当たるものです。

コアが残らないときに確認すること

群発のクラッシュでコアが無い場合、まずコア出力の設定を疑います。core(5)のマニュアルは、コアが書かれない条件を挙げています。

• RLIMIT_CORE(コアファイルサイズ)やRLIMIT_FSIZEが0
• 出力先のファイルシステムが満杯、またはread-only
• 出力先のディレクトリが存在しない

ただし、コアをプログラムにパイプする設定のときは、RLIMIT_COREは無視されます。systemdのホストはこの方式です。

cat /proc/sys/kernel/core_pattern
ulimit -c

core_patternが|/usr/lib/systemd/systemd-coredumpで始まっていれば、コアはsystemd-coredumpに渡っています。その場合は、systemd-coredump側の設定が効きます。coredump.confのマニュアルでは次のとおりです。

• Storage=はnone、external(既定)、journalのいずれかです。externalなら/var/lib/systemd/coredump/に保存されます。
• ProcessSizeMax=は、処理するコアの最大サイズです。64ビットのシステムでは既定が32Gです。超えるコアは保存されても、スタックトレースは作られません。
• Storage=noneとProcessSizeMax=0の組み合わせは、ログ1行を除いてコアの処理を止めます。

つまり、Storage=noneに設定されていたり、保存先の容量が足りなかったりすると、クラッシュ自体は起きていても証拠が残りません。

保存先を確認し、必要ならcoredump.confを調整してから、次のクラッシュを待ちます。1件でも完全なコアがあれば、coredumpctl debugでgdbを起動できます。

# 直近のコアでgdbを起動
coredumpctl debug claude
 
# コアをファイルに書き出す
coredumpctl dump claude --output=/tmp/claude.core

書き出したコアには、環境変数やセッションの内容が含まれる可能性があります。issueなどに添付する前に、中身を確認してください。報告者も、コアファイル自体は手元に残してあり、求められれば提供すると書いています。

運用で効きそうな見方

公式の修正は出ていないため、次の点は報告の範囲での整理です。

同時に動く数を把握する。報告された群発クラッシュは、複数のバージョンのプロセスが同じ秒に終了しています。同時実行の数と照らし合わせるため、クラッシュの時刻とプロセス数を一緒に記録します。

ps -ef | grep -c '[c]laude'

バージョンを固定しても逃げられるとは限らない。報告者は、2.1.231から2.1.243までのポイントリリースを渡って落ちたと書いています。#60215(x86_64のUbuntu、Claude Code 2.1.143)でも、報告者はClaude Code 2.1.112に戻す回避策を試すと書いていました。ARM64向けの動作確認済みバージョンについて、issueに公式の回答はありません。

他の症状と混ぜない。同梱のBunに絡むクラッシュは、OSや条件ごとに別の報告があります。たとえばWindowsのARM64はclaude.exeがWindows ARM64でクラッシュする原因と対処法、GitHub Actions上のtsconfig.jsonまわりはclaude-code-actionのtsconfig.jsonクラッシュが別の話です。症状が違えば、対処も別になります。

glibcとmuslの取り違えでlibstdc++.so.6系のエラーが出る場合は、症状が異なります。その対処はlibstdc++.so.6エラーの原因と対処で扱っています。Illegal instructionと表示される場合は、Illegal instructionエラーの原因と対処の領分です。

同じ問題の先行報告

#89539の報告者は、#60215を同じ系統のクラッシュと見ています。#60215はUbuntu 24.04(x86_64、glibc 2.39)での報告で、Bun 1.3.14のsegfaultが、セッション中に予測できない形で出ていました。2.5時間ほどの使用後に落ち、メモリは逼迫していません。issueは重複(duplicate)として閉じられ、staleラベルが付いています。

2つの報告に共通する点は次のとおりです。

• 決まった操作が引き金になっていない
• 長めの使用の途中で落ちる
• メモリ不足ではない
• クラッシュの時点では、Bun側にシンボルが無く解析が難しい

#89539の側は、ARM64でも起きていること、複数のリリースをまたぐこと、スタック破損の痕跡があることを加えています。

issueに情報を足すとき

同じ症状に当たったとき、報告に足すと役立つ情報を挙げます。#89539の報告者が出している項目に沿った形です。

• Claude Codeのバージョンと、同梱のBunのバージョン
• OS、カーネル、アーキテクチャ、glibcのバージョン
• coredumpctl listの件数とシグナルの内訳
• クラッシュ時の同時プロセス数
• コアが取れた場合のバックトレース(環境変数の断片が混ざっていないかも含めて)

報告者が出した問い、つまり「ARM64固有か」「シンボル付きのバックトレースを得る方法はあるか」「動作確認済みのバージョンはあるか」には、issueのコメントに公式の回答はありません。同じ環境の人がデータを重ねると、切り分けが進みます。

まとめ

今回のクラッシュは、起動時のglibc 2.44の不具合とは別の、セッション途中に出るSIGABRT中心の報告です。原因は未特定で、直す手段も示されていません。当面できるのは、coredumpctlで件数とコアの有無を押さえ、コアが残らない設定を直し、完全なコアが取れた1件を報告に足すことです。