libstdc++.so.6エラーの原因と対処 — Claude Code
Claude Codeのインストール後に「libstdc++.so.6」が見つからないと出るのは、musl向けバイナリの取得ミスか、musl環境でのライブラリ不足が主な原因です。判定コマンドと環境別の対処をまとめます。
「libstdc++.so.6」エラーはmusl/glibcの取り違えかライブラリ不足のサイン
Claude Codeをインストールした直後、コマンドを実行すると次のようなエラーで止まる場合があります。
Error loading shared library libstdc++.so.6: No such file or directorylibgcc_s.so.1が同じ文脈で出ることもあります。どちらも共有ライブラリが見つからないという表示ですが、原因は1つとは限りません。システムに合わないバイナリ変種をインストーラーが取得したのか、本当にライブラリが入っていない環境なのか。この2通りで、直し方が正反対になります。
Linux向けのバイナリには、glibc(GNU C Library)向けとmusl向けの2系統があります。Ubuntu・Debian・RHELなど大半のディストリビューションはglibc、Alpine Linuxはmuslを使います。Cの標準ライブラリの実装が違うので、一方向けのバイナリはもう一方では動きません。Claude Codeのインストーラーは、環境を判定して取得するバイナリを選びます。
厄介なのは、glibcのシステムにmuslのクロスコンパイル用パッケージが入っている場合です。インストーラーが環境をmuslと誤認し、musl向けバイナリを落としてしまうことがあります。
最初の1分で試す切り分け
対処を選ぶ前に、実行環境のlibcと、不足しているライブラリを確かめます。1つ目は、システムのlibcを調べるコマンドです。
ldd --version 2>&1 | head -1出力にGNU libcまたはGLIBCがあればglibc、muslがあればmuslです。2つ目は、インストール済みのclaudeが何を読み込めずにいるかを調べるコマンドです。
ldd "$(command -v claude)" | grep "not found"not foundの行に出たライブラリが、今回足りないものです。何も出ないのにエラーが続くなら、共有ライブラリ以外の原因を疑う段階です。直したあとはclaude --versionが実行できるかで、インストールが通ったかを確かめます。
対処1 — glibc環境なのにmuslバイナリを取得していた場合
ldd --versionがGNU libcを返すのにエラーが出るなら、インストーラーの誤判定です。インストールを削除してから、インストールスクリプトを流し直します。
curl -fsSL https://claude.ai/install.sh | bash同じ誤判定が繰り返される環境では、正しいバイナリを手動で選べます。リリースごとに公開されているマニフェストに、プラットフォームごとのダウンロード情報が載っています。
https://downloads.claude.ai/claude-code-releases/{VERSION}/manifest.json{VERSION}を対象のバージョン番号に置き換えて参照します。誤判定が続く場合は、GitHubのissue(github.com/anthropics/claude-code/issues)に報告します。issueにはldd --versionとls /lib/libc.musl*の出力を添えます。
対処2 — 実際にmuslベースの環境にいる場合
ldd --versionがmuslを返したなら、取り違えではありません。musl環境で動かそうとして、実行時に必要な共有ライブラリが足りていないだけです。
Alpine Linuxは、インストールコマンドに必要なbashとcurlも既定では入っていません。公式のインストールコマンドがnot foundで失敗するのはこのためです。先にこの2つも含めて導入します。
apk add bash curl libgcc libstdc++ ripgrepripgrepはAlpineのcommunityリポジトリにあります。apkがパッケージを見つけられないと報告したら、/etc/apk/repositoriesにcommunityリポジトリを足し、索引を更新してからapk addをやり直します。
echo "https://dl-cdn.alpinelinux.org/alpine/v3.22/community" >> /etc/apk/repositories
apk update
apk add bash curl libgcc libstdc++ ripgrepURLのv3.22は、使っているAlpineのバージョンに合わせて書き換えます。
最後に、パッケージ版のripgrepを使わせるため、settings.jsonのenvにUSE_BUILTIN_RIPGREPを0で設定します。
{
"env": {
"USE_BUILTIN_RIPGREP": "0"
}
}この環境変数が、Claude Code同梱のripgrepではなくシステム側のripgrepを使わせるスイッチです。
Alpineならapkのパッケージで入れる選択肢もある
Alpineでは、インストールスクリプトの代わりに、公式のapkリポジトリから入れる方法もあります。鍵とリポジトリを登録してapk add claude-codeを実行する形です。
wget -O /etc/apk/keys/claude-code.rsa.pub \
https://downloads.claude.ai/keys/claude-code.rsa.pub
echo "https://downloads.claude.ai/claude-code/apk/stable" >> /etc/apk/repositories
apk add claude-codestableの代わりにlatestのリポジトリを追うには、/etc/apk/repositoriesからstableの行を削除してlatestの行を登録します。stableの行を残したまま足すと、リポジトリが二重になります。登録した鍵はsha256sum /etc/apk/keys/claude-code.rsa.pubで検証できます。公式が示す期待値は395759c1f7449ef4cdef305a42e820f3c766d6090d142634ebdb049f113168b6です。更新はapk update && apk upgrade claude-codeで行います。
musl系はAlpineだけではない
公式のセットアップ手順は、「Alpineおよびその他のmusl/uClibcベースのディストリビューション」を同じ節で扱っています。ディストリビューションが違っても、必要なものは変わりません。インストールコマンド用のbashとcurl、実行時のlibgcc・libstdc++・ripgrep、そしてUSE_BUILTIN_RIPGREP=0の設定です。
パッケージ管理のコマンドはapkとは限らないので、各ディストリビューションで同等のパッケージ名を調べます。動作環境として挙げられているAlpineは3.19以降です。
CIとコンテナで判定結果をログに残す
DockerイメージやCIでは、インストール手順の直後にldd --versionとldd "$(command -v claude)" | grep "not found"を1行ずつ差し込んでおくと、ビルドログに判定結果が残ります。後でエラーが出たとき、どちらのlibcだったかをすぐ辿れます。
glibcベースのイメージにmuslのクロスコンパイル環境を足す構成は、冒頭の誤判定の条件にそのまま当てはまります。ツールチェーンを足す前後で、claude --versionが通るかどうかも併せて確かめられます。
npmで入れた場合のバイナリ選択
npmでインストールしても、バイナリの選択は避けて通れません。ネイティブバイナリは、プラットフォーム別のオプション依存パッケージとして配られます。公式が挙げる対応プラットフォームは次の8つです。
| 区分 | プラットフォーム |
|---|---|
| macOS | プラットフォームdarwin-arm64 darwin-x64 |
| Linux(glibc) | プラットフォームlinux-x64 linux-arm64 |
| Linux(musl) | プラットフォームlinux-x64-musl linux-arm64-musl |
| Windows | プラットフォームwin32-x64 win32-arm64 |
社内のnpmミラーを経由している場合は、メタパッケージに加えて、8つの@anthropic-ai/claude-code-*プラットフォームパッケージがすべてミラーされている必要があります。--omit=optionalや.npmrcのoptional=falseでオプション依存を無効にしていると、バイナリそのものが入りません。この場合のエラーはError: claude native binary not installedで、ライブラリ不足とは別の系統の問題です。
--ignore-scriptsでpostinstallが飛ばされた場合も同じエラーになります。メッセージが案内するとおりnode node_modules/@anthropic-ai/claude-code/install.cjsを実行するか、フラグなしで入れ直します。対応表にないプラットフォームにはバイナリが配られず、FreeBSDではインストーラーが未対応と報告します。v2.1.205より前はFreeBSDをLinuxとして扱い、動かないバイナリを落としていました。
ライブラリ以外の理由でバイナリが起動しない場合
Linuxでバイナリが起動しない症状は、libstdc++.so.6だけではありません。メッセージごとに原因が異なるので、似た見た目のエラーと混同しないよう並べます。
| エラー | 原因の系統 |
|---|---|
Error loading shared library ... | 原因の系統本記事の対象。バイナリ変種の取り違え、またはmuslでのライブラリ不足 |
Illegal instruction | 原因の系統CPUアーキテクチャの不一致、またはAVX命令の欠落 |
cannot execute binary file: Exec format error(WSL) | 原因の系統WSL1での既知の不具合 |
Error: claude native binary not installed(npm) | 原因の系統オプション依存が入っていない |
Bus error(セッション中) | 原因の系統実行ファイルをディスクから読めなくなった |
Illegal instructionは、2つの原因に分かれます。1つ目は、x86のバイナリをARMサーバーに入れたようなアーキテクチャの不一致で、uname -mの結果と、受け取ったバイナリの種類が合っているかを見ます。
2つ目は、CPUにAVX命令がない場合です。2013年より前のIntelやAMDのCPUと、ハイパーバイザーがAVXをゲストに渡していない仮想マシンが該当します。VPSやVMではgrep -m1 -ow avx /proc/cpuinfoを実行し、空なら未対応です。ネイティブバイナリ側に回避策はなく、npmなど別の導入方法も同じバイナリを取得するため解決しません。この件はGitHubのissue #50384で状況が追跡されており、報告するときはCPUの型番(Linuxならgrep -m1 "model name" /proc/cpuinfo、macOSならsysctl -n machdep.cpu.brand_string)を添えます。
WSLでExec format errorが出る場合は、WSL1が原因です。バイナリのプログラムヘッダーの変更をWSL1のローダーが扱えない不具合で、GitHubのissue #38788で追跡されています。PowerShellからwsl --set-version <DistroName> 2でWSL2に変換するのが最も素直な直し方です。WSL1に留まる場合は、動的リンカー経由でバイナリを呼び出す関数を~/.bashrcに足す回避策が示されています。
セッションの途中でBus errorが出て終了する場合は、claude自身の実行ファイルが読めなくなったことが原因の1つです。ファイルが切り詰められた、ネットワークストレージ上で実行中に削除された、といった状況です。クラッシュレポートにoh no: Bun has crashedと出ても、実行ファイルが読めなくなったのが原因なら、実行基盤側のバグではありません。新しいセッションを始めれば続けられます。
libcの種類はmusl/glibcの切り分けで確定できても、Illegal instructionのようにCPU側が原因のエラーは、ここで挙げた手順では直りません。表のどれに当たるかを先に見分けると、無駄な再インストールを避けられます。
まとめ
エラーメッセージがlibstdc++.so.6でも、最初に見るのはライブラリの有無ではなく、ldd --versionが示すlibcの種類です。誤判定が起きるのはglibcにmuslのクロスコンパイル環境を足した構成なので、ツールチェーンを足したイメージではldd --versionの出力をビルドのたびに残しておくと切り分けが速くなります。インストール全体の切り分けはClaude Codeインストールエラーの切り分けチェックリスト、Ubuntu特有の依存関係はClaude Code Ubuntuインストールにあります。Agent SDKでもLinux上でmusl版バイナリが誤って優先される別種のバグが報告されており、Claude Agent SDKがLinuxでmusl版バイナリを優先するバグの原因と対処で扱っています。