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

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

Claude Codeのネイティブインストールを使うLinux環境で、claude --versionを含むあらゆる起動がSIGSEGV(セグメンテーション違反)で落ちることがあります。引数も設定も関係なく、毎回再現します。

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

シェルにはsegmentation fault (core dumped)と表示され、終了コードは128+11の139になります。CLIが一切起動できないので、claude updateによる自己修復も効きません。

設定の影響でないことは、環境変数を空にした再現報告で裏づけられています。env -i HOME=/tmp/fakehome PATH=/usr/bin TERM=dumbで起動しても同じく139で落ち、~/.claude.jsonなどのユーザー設定は原因から外れます。

原因を先に言うと、glibc 2.44を採用したLinuxで、Claude Code同梱のメモリアロケータmimallocがglibcのfreeを上書きしていました。mainに入る前の初期化で呼ばれる無害なfree(NULL)が、そこで落ちます。GitHub issue #89334で報告され、v2.1.245で修正されています。

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

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

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

mimallocが公開したfreeは、引数がNULLかどうかを確認していませんでした。C言語の規格(C17 7.22.3.3p2)では、free(NULL)は何もしない呼び出しと定められています。glibc 2.44のnewlocaleは、newlocale.cの291行目でfree (tmp_buffer);を無条件に呼びます。ロケール名を正規化する一時バッファが不要なとき、tmp_bufferはNULLのままです。

Issueのコメントには、Bunの静的初期化がnewlocale(LC_ALL相当のマスク, "C", NULL)を呼ぶ様子が載っています。NULLチェックの無いmimalloc版freeは、ポインタをそのままアドレス計算に使い、アドレス0を読んでクラッシュします。

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のロケール処理関数で、Bunの初期化処理からmainに入る前に呼ばれます。CLI側のコードより先に落ちるので、引数やLC_ALL=Cを変えても症状は変わりません。

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

Issueに集まった報告を時系列に並べると、配信側の動きは次のとおりです。

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

v2.1.245では、アロケータシンボルの公開自体がなくなりました。

glibc側の境界は、Issueのコメントで次のように共有されています。

境界は2.43のリリースと、2.44になる開発系列の間にあります。glibc 2.44を先に導入していた環境でも、v2.1.241は動いていました。glibcを戻さなくても、Claude Code側のバージョンで切り分けられます。

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

起動できるバージョンと起動できないバージョンが手元に混在している場合は、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(未定義)行なので、対象に含めません。

検索パターンをfreeのような完全一致にすると、対象ビルドでも何もヒットしません。シンボル名は@@GLIBC_2.2.5のようにバージョン接尾辞を伴うので、@@までをパターンに含めてください。Issueのコメントでも、このreadelfチェックは「CLIが起動できず--versionで確認できないときの起動前チェック」として共有されています。

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で止まれば、この記事の不具合と一致します。

起動時のSIGSEGVでも、libstdc++.so.6が見つからない型のエラーは原因が別です。切り分けは「libstdc++.so.6」エラーの記事と、Claude Codeインストールエラーの切り分けチェックリストにあります。

今すぐ使える回避策

対象バージョンで起動できないときは、ネイティブインストーラーが管理するシンボリックリンクを、動作する古いバージョンへ張り替えます。~/.local/bin/claudeは~/.local/share/claude/versions/配下へのリンクです。このディレクトリには、リンク先と新しい2バージョンなどが残ります。目的のバージョンが残っていない場合は、下の直接取得を使います。

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

リンクの張り替えだけでは戻る可能性があります。Issueには、手動で戻した環境が気づかないうちにv2.1.243へ戻されたという報告が複数あります。公式ドキュメントでは、自前のシンボリックリンクは自動更新で上書きされないと説明されているため、報告とは食い違います。確実に止めるには、settings.jsonのenvキーでDISABLE_AUTOUPDATERを"1"にして、自動更新を止めます。

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

claude doctorを実行し、Auto-updatesの行がdisabled (set by env: DISABLE_AUTOUPDATER)と表示されれば反映されています。止まるのはバックグラウンドの自動更新だけで、claude updateとclaude installは手動で実行できます。手動更新も止めたいときは、より厳格なDISABLE_UPDATESを使います。

回避が不要になったら、自動管理に戻せます。claude doctorは、ネイティブインストーラーが作っていないランチャーを検出すると報告します。~/.local/bin/claudeを削除してclaude updateを実行すれば、Claude Code側がランチャーを管理する状態に戻ります。

古いバージョンがversions/に残っていない場合は、バイナリを直接取得する方法がIssueで共有されています。install.shは引数にかかわらず常にlatestを解決するので、次のようにバージョン指定のURLから取ります。

curl -fsSL https://downloads.claude.ai/claude-code-releases/2.1.241/linux-x64/claude -o claude
chmod +x claude

取得したバイナリはDISABLE_AUTOUPDATER=1つきで動かします。

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

v2.1.245のchangelogには、この修正が1行で載っています。

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

Issueでは、v2.1.243でSIGSEGVだったArch Linux(glibc 2.44)で、v2.1.245は--versionが3回続けて終了コード0を返し、TUIの起動まで進んだと報告されています。.dynsymの総エントリ数は、v2.1.241が1196、v2.1.243が1224、v2.1.245が1196です。ELFの種別はどれも非PIEのままで、修正は公開シンボルを取り除く側で行われました。

この不具合は、ELFバイナリとglibcのシンボルバージョニングが組み合わさって起きます。報告・修正の対象は、いずれもglibc 2.44のLinuxです。回避と再発防止の対象は、glibcを使うLinuxのネイティブインストールに絞って考えられます。

再発を避けたいときは、autoUpdatesChannelを"stable"にする方法があります。公式ドキュメントでは、"stable"は「おおむね1週間前のバージョンで、重大な回帰を含むリリースをスキップする」チャンネルです。v2.1.242の約4時間後にv2.1.243のビルドが出て、v2.1.245の修正は、翌日のUTC早朝(07:33)に報告されています。Issueのコメントでは、当時のstableはv2.1.231を指していたと共有されています。stableなら、v2.1.242とv2.1.243を避けられた計算です。"latest"のままなら、即日リリースの不具合を最初に踏む可能性が残ります。報告の時点でstableはまだv2.1.231のままで、v2.1.245に上がるのはlatestより後になります。

/configで"latest"から"stable"に切り替えると、現在のバージョンに留まるか、ダウングレードを許すかを聞かれます。留まるを選ぶと、minimumVersionにそのバージョンが入ります。Homebrewではcask名で選び、claude-codeがstable、claude-code@latestがlatestです。apt・dnf・apkのリポジトリにもstableとlatestがあります。

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

• リンクだけでは戻る報告がある: シンボリックリンクを張り替えても、最新版へ戻されたというIssueの報告があります。DISABLE_AUTOUPDATERを設定しておけば、この問題を避けられます。
• 更新成功の記録は当てにならない: 更新結果は~/.claude/.last-update-result.jsonに残ります。Issueの報告では、v2.1.242への更新が"outcome":"success"と記録された59秒後に最初のSIGSEGVが出ています。更新ログが成功でも、起動できる保証にはなりません。
• ホストとコンテナで結果が変わる: $HOMEをコンテナにバインドマウントすると、同じバイナリでも結果が分かれます。ホスト(Ubuntu、glibc 2.43)では動き、Fedora 45のコンテナ(glibc 2.44)ではSIGSEGVになる報告があります。
• 再インストールでは直らない: claude installの引数は、インストール処理が始まる前にCLIが落ちるため反映されません。v2.1.287のclaude install --helpは、[target]にstable・latest・具体的なバージョンを取ると表示します。一方claude update --helpのオプションは-hだけで、バージョンは指定できません。

よくある質問

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

公式ドキュメントでは、npmパッケージはプラットフォームごとの実行ファイル(linux-x64やlinux-x64-muslなど)をoptionalDependencies経由で取得します。配布経路よりも、glibc 2.44の環境でv2.1.242かv2.1.243のLinux x64向け実行ファイルが動くかどうかが分かれ目です。Issueで再現が報告されているのは、いずれもx86-64のLinuxです。

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

Homebrew・WinGet・Linuxパッケージマネージャの各インストールは、既定でClaude Codeの自動更新をしません。明示的にアップグレードしない限り、対象バージョンは入りません。すでに対象バージョンを導入済みなら、ネイティブインストールと同じく、glibc 2.44かどうかが症状の有無を分けます。WinGetはWindows向けで、glibcを使わないためこの不具合の対象外です。

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

readelfはbinutilsパッケージに含まれます。Debian・Ubuntu系はapt install binutils、RHEL・Fedora系はdnf install binutilsで入ります。objdump -Tでも同じ動的シンボルテーブルを見られます。

まとめ

v2.1.242とv2.1.243を使っていて、glibc 2.44のLinuxで--versionすら落ちるなら、この不具合です。readelfで@@つきのアロケータシンボルを確かめ、ln -sfnで戻してDISABLE_AUTOUPDATERを設定すれば復旧できます。v2.1.245以降は修正済みです。同じ起動失敗でもmacOS 12の例は原因が別で、v2.1.258に載っています。