Claude CodeがSIGSEGVで起動直後にクラッシュする原因と対処法

起動直後にSIGSEGVで落ちる症状

Claude Codeのネイティブインストールを使うLinux環境で、claude --versionを含むあらゆる起動がSIGSEGV(セグメンテーション違反)で落ちることがあります。設定ファイルやコマンドライン引数の内容に関係なく、100%の確率で再現するのが特徴です。

$ claude --version
[1]    88020 segmentation fault (core dumped)
$ echo $?
139

シェルにはsegmentation fault (core dumped)と表示され、終了コードは128+11の139になります。CLIが一切起動できないため、claude updateによる自己修復も効きません。原因を先に言うと、glibc 2.44を採用したLinuxディストリビューションで、Claude Codeが同梱するメモリアロケータmimallocがglibc本体のfreeを上書きしてしまい、mainに入る前の初期化処理中に呼ばれる無害なfree(NULL)で落ちるという不具合です。GitHub issue #89334で報告され、Claude Code v2.1.245で修正済みです。

原因はglibc 2.44とmimallocの相互干渉

mimallocとは、Claude Codeが同梱しているメモリアロケータです。通常はmallocやfreeをアプリケーション内部だけで使いますが、v2.1.242のビルドではmalloc free calloc reallocなどのシンボルをglibc互換の形(free@@GLIBC_2.2.5のような@@GLIBC_バージョンつき)でバイナリの外側に公開してしまいました。

Linuxの動的リンカーは、実行ファイル自身が公開するシンボルをライブラリより優先して解決します。この結果、glibc内部が本来呼ぶはずのfreeまで、Claude Codeバイナリ内のmimalloc版freeに置き換わってしまいました。これをシンボルの相互干渉(インターポジション)と呼びます。

問題はここからです。mimallocが公開したfreeは、引数がNULLかどうかをまったくチェックしていませんでした。C言語の規格(C17 7.22.3.3p2)ではfree(NULL)は何もしない無害な呼び出しと定められており、glibcのnewlocaleもこれに従って、内部でfree(NULL)を呼びます(呼び出し元はBunの静的初期化処理)。ところがNULLチェックの無いmimalloc版freeは、ポインタをそのままメモリのアドレス計算に使ってしまい、アドレス0への読み込みでクラッシュします。バックトレースは次のように、glibcのnewlocaleからfreeに入った直後で止まります。

Signal: 11 (SEGV) si_code: SEGV_MAPERR
#0  0x0000000001d10458 in free ()            <- claudeバイナリ内、libcではない
#1  0x00007ffff7c3530a in newlocale () from /usr/lib/libc.so.6
...
#16 0x00007ffff7c27892 in __libc_start_main () from /usr/lib/libc.so.6

newlocaleはglibcが提供するロケール処理関数の一つで、Claude Codeに組み込まれたランタイム(Bun)の静的初期化処理からmainに入る前、つまりCLI側のコード実行より先に呼ばれます。これが、引数やロケール環境変数(LC_ALL=C)を変えても症状が変わらない理由です。

影響を受けるバージョンとglibcの組み合わせ

同じマシン・同じglibcで検証されたバージョン別の結果は次の通りです。

v2.1.242は不具合の発覚後にいったん配信から外れましたが、同日中に出たv2.1.243も同じアロケータ露出を引き継いでおり、症状は解消していませんでした。v2.1.245でアロケータシンボルの露出そのものが取り除かれ、.dynsymのエントリ数がv2.1.241と同じ水準に戻っています。

glibc側では、Issueのコメントで2.36・2.39〜2.43の各バージョンでは再現せず、2.43.9000(Fedora Rawhide)と2.44(Arch Linux)で再現するとの検証結果が共有されています。境界はglibc 2.43のリリースとその後の開発版の間にあり、Arch Linux、CachyOS、Fedora Rawhideなど最新のglibcを早く取り込むディストリビューションで表面化しました。Ubuntu 24.04やDebian 12のようにglibcの更新が緩やかな環境では、影響のあるバージョンを使っていてもこの経路には到達しません。

自分の環境が影響を受けるか診断する

起動できるバージョンと起動できないバージョンが手元に混在している場合は、readelfでアロケータシンボルの有無を確認します。CLIが起動しなくても、バイナリファイル自体はreadelfで読めます。

readelf --dyn-syms --wide ~/.local/share/claude/versions/<バージョン番号> \
  | grep -E ' (malloc|free|calloc|realloc)@@'

free@@GLIBC_2.2.5のように@@(二重)を含む行が出力されればアロケータを露出している対象ビルド、何も出力されなければ影響を受けないビルドです。@が一重の行(free@GLIBC_2.2.5)は、バイナリがglibc本来のfreeを通常どおり参照しているだけのUND(未定義)行なので対象に含めません。Issueのコメントでも、このreadelfチェックが「CLIが起動できずに--versionで確認できない状況での、起動前チェック」として共有されています。ただしシンボル名は@@GLIBC_2.2.5のようにバージョン接尾辞を伴うため、grepの検索パターンをfreeのような完全一致にすると、対象ビルドでも何もヒットしないという見落としが起きます。バージョン接尾辞の@@までを検索パターンに含めてください。

gdbが使える環境では、freeにブレークポイントを置いて実際の引数を見ることもできます。

gdb -batch -ex 'break free' -ex 'run --version' \
  -ex 'printf "free arg = %p\n", $rdi' \
  --args ~/.local/share/claude/versions/<バージョン番号> --version

free arg = (nil)と表示された直後にSIGSEGVで止まれば、この記事で扱っている不具合と一致します。

今すぐ使える回避策

対象バージョンで起動できなくなった場合、lnコマンドでネイティブインストーラーが管理するシンボリックリンクを、動作する古いバージョンへ張り替えます。Claude Codeのネイティブインストーラーは~/.local/bin/claudeを~/.local/share/claude/versions/配下へのシンボリックリンクとして管理しており、過去にインストールしたバージョンはこのディレクトリに残っています。

ln -sfn ~/.local/share/claude/versions/2.1.241 ~/.local/bin/claude

このリンク張り替えだけでは不十分です。ネイティブインストーラーは起動のたびにバックグラウンドで更新を確認し、次に起動したタイミングでシンボリックリンクを最新版へ戻してしまいます。Issueの複数の報告者が「シンボリックリンクを戻したはずが、いつの間にか壊れたバージョンに巻き戻されていた」と共有しており、settings.jsonのenvキーでDISABLE_AUTOUPDATERを"1"に設定して自動更新そのものを止める必要があります。

{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  }
}

claude doctorを実行し、Auto-updatesの行がdisabled (set by env: DISABLE_AUTOUPDATER)と表示されれば設定が反映されています。DISABLE_AUTOUPDATERが止めるのはバックグラウンドの自動更新確認だけで、claude updateやclaude installは引き続き手動で実行できます。配布側の都合で手動更新も含めて完全に止めたい場合は、より厳格なDISABLE_UPDATESを使います。

v2.1.245で修正済み、再発条件に注意

v2.1.245の修正内容は次のとおりです。

## 2.1.245
- Fixed a crash on startup on Linux distributions that ship glibc 2.44 (for example Arch Linux, CachyOS and Fedora Rawhide)

修正はmimalloc側のアロケータシンボルをバイナリの外へ露出しない形に戻すことで行われ、.dynsymのエントリ数はv2.1.241の水準に戻っています。

この不具合の型はglibc固有の仕組みに依存します。原因は実行ファイルが公開する@@GLIBC_バージョンつきシンボルによる相互干渉で、これはELFバイナリとglibcのシンボルバージョニングという、Linux特有の動的リンク機構が組み合わさって初めて起こります。Issueやchangelogで報告・修正対象になっているのも、いずれもglibc 2.44を採用したLinux環境です。したがって回避と再発防止の対象は、glibcを採用したLinuxのネイティブインストールに絞って考えるのが妥当です。

再発そのものを避けたい場合は、autoUpdatesChannel設定を"stable"に切り替える方法があります。"stable"チャンネルは「重大な回帰を含むリリースをスキップする、おおむね1週間遅れのバージョン」を配信する設計で、v2.1.242とv2.1.243はどちらも登場から1日足らずで次のビルドに置き換わっています。"latest"チャンネルを使い続ける限り、今回のような即日リリースの不具合を最初に踏む可能性は残ります。

回避策でよくあるつまずき

• リンクだけでは戻る: シンボリックリンクを張り替えても、DISABLE_AUTOUPDATERを設定しない限り次回起動時に最新版へ巻き戻されます。稼働中のセッションを古いバージョンで使い続けていても、バックグラウンドでの再ダウンロードと張り替え自体は止まりません。
• LD_PRELOADは効かない: 実行ファイル自身が公開するシンボルは、動的リンカーの解決順序でLD_PRELOADされたライブラリよりも優先されるため、別のアロケータを先読みさせても効果がありません。
• ホストとコンテナで結果が変わる: $HOMEをコンテナへバインドマウントする構成では、ホスト側のglibcが2.43で問題なく起動していても、glibc 2.44を採用したコンテナイメージの中で同じバイナリを実行するとSIGSEGVになるケースが報告されています。同一バイナリでの再現有無は、実行環境のglibcバージョンで決まります。
• 再インストールでは直らない: claude install <バージョン>はインストール処理自体が完了する前にCLIがクラッシュするため、指定したバージョン番号は実質的に反映されず、~/.local/bin/claudeは壊れたバイナリを指したままになります。確実に戻すには、ln -sfnでシンボリックリンクを直接張り替えてください。

よくある質問

npm経由でインストールした場合も影響を受けますか

はい。公式ドキュメントによれば、npmパッケージはプラットフォームごとの実行ファイル(@anthropic-ai/claude-code-linux-x64のような形)をoptionalDependencies経由で取得するだけで、ネイティブインストーラーと同じバイナリをインストールします。配布経路がインストーラー経由かnpm経由かは関係なく、glibc 2.44環境でv2.1.242またはv2.1.243のLinux x64向けバイナリを実行すれば同じ経路でクラッシュします。linux-x64-musl向けビルドやarm64版での再現は確認されていません。

HomebrewやLinuxパッケージマネージャ(apt/dnf/apk)でインストールした場合は

Homebrew・apt・dnf・apkの各インストールはデフォルトで自動更新しないため、明示的にアップグレードコマンドを実行しない限り対象バージョンを取得しません。すでに対象バージョンを導入済みの環境では、ネイティブインストールと同じくglibc 2.44かどうかが症状の有無を分けます。なお、WinGetはWindows向けの配布経路で、Windowsはglibcを使わないためこの不具合の対象外です。

readelfがインストールされていない環境ではどう確認しますか

readelfはLinuxのbinutilsパッケージに含まれています。Debian・Ubuntu系はapt install binutils、RHEL・Fedora系はdnf install binutilsで導入できます。readelfが使えない場合はobjdump -Tでも同じ動的シンボルテーブルを確認できます。

まとめ

Claude Codeが起動直後にSIGSEGVで落ちる不具合は、v2.1.242とv2.1.243が同梱のmimallocアロケータをglibc互換シンボルとして誤って公開し、Bunの初期化処理から呼ばれるglibcのnewlocale内部の無害なfree(NULL)とぶつかったことが原因でした。readelf --dyn-symsでアロケータシンボルの有無を確認し、影響を受けているバージョンならln -sfnでv2.1.241以前へ戻したうえでDISABLE_AUTOUPDATERを設定すれば復旧します。v2.1.245で修正済みですが、"latest"チャンネルのまま運用する限り同種の即日リリース不具合を最初に踏む可能性は残るため、安定運用を優先する環境ではautoUpdatesChannelを"stable"にする選択肢があります。似た症状でも原因が異なる「libstdc++.so.6」エラーや、起動全般の切り分けはClaude Codeインストールエラーの切り分けチェックリスト、v2.1.258で修正された別系統の起動失敗もあわせて確認してください。