Claude CodeのUbuntu 26.04 segfault — 起動時Bunクラッシュの切り分け

Ubuntu 26.04.1 LTSにClaude Codeを入れると、起動のたびにBunがSIGSEGVかSIGABRTで落ちる。GitHub issue #94462はそう報告しています。原因も修正バージョンも、Issue #94462にはまだ載っていません。分かっているのは症状と、報告者が試した範囲です。

報告されている症状

Claude CodeのIssue #94462は、起動直後に出力も操作もないままBunが落ちると述べています。環境は報告者の記載どおり次のとおりです。

インストール経路は2つです。VS Code拡張と、sudo npm install -g @anthropic-ai/claude-codeで入れたCLI。どちらも同じ落ち方をします。

落ち方は一定ではありません。報告者が貼ったログには、次の2種類のパニックがあります。

panic(main thread): Segmentation fault at address 0x5
oh no: Bun has crashed.
 
panic(main thread): abort() called
oh no: Bun has crashed.

どちらも続けてhttps://bun.report/1.4.3/…のURLが出ます。報告では、シグナルとアドレスは毎回少しずつ違い、まれに起動できても、ほとんどの試行で落ちます。

「毎回同じ場所で落ちる」不具合ではない点が重要です。決まった関数で必ず落ちる型なら、バージョンを変えれば直るかどうかがすぐ分かります。今回は試行ごとに結果が揺れるので、切り分けにも回数が要ります。

同じSIGSEGVでも別件と取り違えない

Claude Codeの起動時クラッシュは、症状が似た別件が複数あります。見分ける材料を並べます。

glibc 2.44の件は、同梱アロケータのfreeがNULLを受けて落ちる確定的な不具合で、v2.1.245で修正されています。経緯とreadelfによる判定はClaude CodeがSIGSEGVで起動直後にクラッシュする原因と対処法にまとめています。そちらの対処(アロケータシンボルの確認や古いバージョンへの切り替え)は、glibc 2.43の本件にそのまま当てはまるとは限りません。

abortで落ちる点も違いです。別の記事にあるLinux ARM64の例は、セッション途中に落ちる型でした。起動前に落ちる本件とは区別されます(Linux ARM64のSIGABRTクラッシュ)。

OSよりカーネルを疑う理由

Ubuntu 26.04が原因だと決めつけるのは早計です。Issueの報告者自身が、そうでない可能性を示す再現結果を書いています。

報告者は同じマシンの上で、Ubuntu 24.04のDockerコンテナを起動し、そこでも同じクラッシュを再現しました。コンテナはホストのカーネルを共有します。コンテナ側のglibcは24.04のものなので、glibc 2.43だけが原因なら再現しないはずです。報告者はこの結果から、ホストのカーネル7.0.0が関係している可能性を挙げています。

ただし、これは報告者の推測です。Issueにはカーネルの原因を示すログも、別カーネルでの検証結果もありません。報告者はSMART検査とメモリ検査(memtesterで2GB・1周)でエラーがなかったことも書いていますが、短い検査なので、ハードウェアの不具合を完全に否定する材料にはなりません。

公式のシステム要件は、Ubuntu 20.04以降と書いています。26.04は範囲内です。「サポート対象外のOSだから落ちる」という説明は成り立たず、少なくとも要件上の問題ではありません。

手元でできる切り分け

原因が特定されていない以上、確かめられるのは「自分の環境がどの条件に当てはまるか」です。落ち方が揺れるので、1回の成否ではなく、複数回の結果で見ます。

まず、環境の基本情報を一度に取ります。

uname -r
ldd --version | head -1
claude --version
ldd "$(command -v claude)" | grep "not found"

claude --version自体が落ちる環境では、後ろ2行の出力が空になることがあります。その場合も、uname -rとglibcのバージョンは取れます。

落ち方が揺れる不具合では、同じ操作を繰り返して終了コードの内訳を見るのが手早い方法です。次のスクリプトは--versionを20回実行し、終了コードごとに数えます。

for i in $(seq 1 20); do
  claude --version >/dev/null 2>&1
  echo $?
done | sort | uniq -c

139はSIGSEGV(128+11)、134はSIGABRT(128+6)です。0だけなら起動時のクラッシュとは別の要因です。0と139・134が混ざれば、Issueの「ほとんど落ちるが、まれに起動する」と同じ型です。ただし、Issueが--versionでも落ちると述べているわけではなく、報告されているのはclaudeの通常起動と拡張の起動です。--versionで再現しなければ、claudeをそのまま数回起動して終了コードを比べてください。

回避策はまだ確立していない

Issueには、報告者が試した回避策も、保守側からの返信もありません。「最後に動いたバージョン」の欄は未記入で、リグレッションかどうかも「不明」とされています。Claude Code側のバージョンを下げれば直る、とは言えない状態です。

試せる手段は、公式ドキュメントに書かれた範囲に限られます。

• 古いバージョンへ戻す: ネイティブインストーラーは~/.local/bin/claudeを~/.local/share/claude/versions/配下へのシンボリックリンクとして管理します。自前のリンクやランチャーに替えても、自動更新とclaude updateはそれを上書きせず、新しいバージョンをversions/に入れるだけだと、公式のセットアップ手順は説明しています。戻す手順の詳細は、glibc 2.44の記事に例があります。
• 自動更新を止める: settings.jsonのenvにDISABLE_AUTOUPDATERを"1"で置きます。claude doctorのAuto-updates行にdisabled (set by env: DISABLE_AUTOUPDATER)と出れば反映されています。
• Bunの更新を待つ: Bunが落ちるクラッシュなので、同梱のBunが更新されれば挙動が変わる可能性があります。Issueはこの点に触れていません。

どのバージョンが動くかは、Issueからは分かりません。戻す先を選ぶには、自分で複数のバージョンを試す必要があります。公式のトラブルシューティングには、バージョン別のバイナリをhttps://downloads.claude.ai/claude-code-releases/{VERSION}/manifest.jsonから手動で取得する方法の記載があります。取得したバイナリは、上の20回ループで評価できます。

試した結果をIssueに残す

この種の不具合では、再現環境の情報が増えるほど原因が絞れます。Issueが有効に使えるのは、次の情報が揃ったときです。

• 発生した環境のuname -rとglibcのバージョン
• 動いた最後のClaude Codeバージョンと、落ち始めたバージョン
• 20回ループの終了コードの内訳
• 起動時に出るbun.reportのURL

カーネルが要因なのか、ハードウェア固有なのかは、別環境の報告が増えて初めて切り分けられます。Issueに寄せられたコメントは1件で、「更新してから同じ症状が出る」という内容です。コメント側の環境情報や再現手順は載っていません。

インストール経路は直接の原因とは限らない

npm経由で入れた場合も、公式ドキュメントでは、npmパッケージはプラットフォーム別のネイティブバイナリを取得して配置するだけで、インストールされたclaudeはNodeを呼びません。つまりnpmでもネイティブインストーラーでも、起動時に動くのは同じバイナリです。Issueで「VS Code拡張とnpm版の両方で落ちる」のは、同じバイナリを使っているからだと読めます。

インストール手段を変えても、同じバイナリである以上、結果は変わらないはずです。Ubuntuへの入れ方そのものはClaude Code Ubuntuインストールに、起動前に失敗するインストールエラー全般の切り分けはClaude Codeインストールエラーの切り分けチェックリストにあります。glibcとmuslのバイナリ取り違えに起因する別の起動失敗は、「libstdc++.so.6」エラーの記事で扱っています。

まとめ

Ubuntu 26.04.1(glibc 2.43)でBunが起動時に落ちる件は、原因も修正もIssueでは示されていません。Dockerの24.04コンテナでも再現した結果は、OSよりホストのカーネルやハード側を疑う材料です。手元ではuname -r・glibc・Claude Codeのバージョンと、20回ループの終了コード内訳を取り、bun.reportのURLとあわせてIssueに残すのが、今できる最も確実な一手です。