Claude CodeがColimaのdevcontainerでUnsupported platformを出すとき

MacでColimaをDockerの実体にしてdevcontainerを使っていると、VS Code拡張の再認証が終わった直後に Unsupported platform: linux-arm64. No compatible Claude Code binary found. が出ることがあります。コンテナはAppleシリコン上のarm64で、バイナリも正しく置かれているのに、です。報告されている回避策はコンテナの再構築で、原因は特定されていません。この記事では、報告の中身、コンテナ内で原因を切り分けるコマンド、再構築以外の選択肢をまとめます。

報告されている状況

Claude Codeのリポジトリにこの現象のissue(#80574)が立っています。報告者の環境は次のとおりです。

再現手順は報告にありません。報告者自身が「ときどき起きる」と書いており、確実に起こす方法はないようです。

issueは2026年10月2日に、無活動を理由にボットが自動でクローズしました。修正版が出たわけではないため、同じ症状は今後も起こる可能性があります。クローズ時のコメントは「まだ該当するなら新しいissueを立ててください」という定型文でした。

出るメッセージは2種類ある

報告者は2つの文言を載せています。

Unsupported platform: linux-arm64. No compatible Claude Code binary found.

別のインスタンスでは、より長いメッセージも見えたとのことです。

ReferenceError: Claude Code native binary at
/home/vscode/.vscode-server/extensions/anthropic.claude-code-2.1.217-linux-arm64/resources/native-binary/claude
exists but failed to launch. This usually means the binary does not match
this system's libc ... Specify a matching binary with
options.pathToClaudeCodeExecutable.

長い方は「バイナリは存在するが起動に失敗した」と言っています。短い方の「対応プラットフォームではない」とは、言っていることが違います。両者が同じ現象の別の見え方なのか、別々の原因なのかは、issueの記載だけでは分かりません。

まず「本当に非対応なのか」を切り分ける

arm64のLinuxは対応プラットフォームです。npm経由のインストールで対応するのは darwin-arm64、darwin-x64、linux-x64、linux-arm64、linux-x64-musl、linux-arm64-musl、win32-x64、win32-arm64 の8つで、linux-arm64 はその1つです。名前のうえでは、このエラーは事実と食い違っています。

報告者は、エラーが出ているコンテナの中で拡張の同梱バイナリを調べています。同じ手順をそのまま使えます。ホストのターミナルから、コンテナに入ります。

docker ps --format '{{.ID}}  {{.Image}}'
docker exec -it -w / <コンテナID> /bin/bash

コンテナの中で、アーキテクチャ、拡張ディレクトリ、バイナリの種類、起動可否の順に見ます。

uname -m
ls ~/.vscode-server/extensions/ | grep anthropic.claude-code
BIN=$(ls -d ~/.vscode-server/extensions/anthropic.claude-code-*/resources/native-binary/claude | tail -1)
file "$BIN"
"$BIN" --version

~ がrootのホームを指す場合は、devcontainerの remoteUser(報告では vscode)のホームに読み替えてください。報告の出力は次のとおりでした。

• uname は aarch64
• file の結果は ELF 64-bit LSB executable, ARM aarch64 ... interpreter /lib/ld-linux-aarch64.so.1(glibc向け)
• --version は 2.1.217 (Claude Code) と表示された

つまり同梱バイナリはコンテナのCPUとlibcに合っていて、手で起動すれば動いています。それでも拡張はエラーを出しています。ここまで合っているなら、バイナリの種類の取り違えより、拡張側の検出か起動の過程に原因があると考えるのが自然です。ただし、その過程のどこで失敗しているかはissueに書かれていません。

libcの取り違えも一応確かめる

長い方のメッセージが指すのはlibcの不一致です。glibcのホストでmusl向けのバイナリを起動すると、/lib/ld-musl-* がなくて失敗します。次の2行で、コンテナ側のlibcを確かめられます。

ldd --version 2>&1 | head -1
ls /lib/ld-musl-* 2>/dev/null

GNU libc と出て、muslのローダが見つからなければ、glibcの環境です。この場合は file の結果にある ld-linux-aarch64 と一致します。Alpineのようなmuslベースのイメージでは話が変わります。その場合の準備はClaude CodeをAlpine Linuxで動かす手順に、取り違えの見分け方はmuslとglibcのバイナリ不一致の記事にあります。

再構築の前に、ウィンドウの再読み込みを試す

再構築は認証情報を含むホームを捨てるので、重い手段です。拡張の起動に関わる軽い操作が先にあります。VS Codeの公式ページには、拡張が表示されないときの手順として、VS Codeを再起動するか、コマンドパレットのDeveloper: Reload Windowを実行する、と書かれています。サインイン後に「Not logged in」が出て、サインイン画面が自動で開き直らないときの案内も同じ操作です。

このissueの症状に効くという報告はありません。ただ、再構築ほど失うものが少なく、試す価値はあります。

直し方の選択肢

1. キャッシュなしで再構築する(報告された回避策)

報告者が見つけた方法は、コマンドパレットからDev Containers: Rebuild Container Without Cacheを実行し、もう一度認証することです。これで動くようになったと報告されています。

注意点は、再構築でコンテナのホームが捨てられることです。devcontainerの公式ページによると、ホームディレクトリは再構築のたびに破棄され、サインインもやり直しになります。この報告者の場合、認証の切れ目で起きる現象に対して、認証を毎回やり直す方法で当たっていることになります。

2. claudeProcessWrapperで別のclaudeを指す

VS Code拡張には claudeCode.claudeProcessWrapper という設定があります。説明はこうです。Claudeプロセスの起動に使う実行ファイルで、同梱バイナリのパスがあれば引数として渡されます。拡張のビルドが自分のプラットフォーム向けのバイナリを含まないときは、別途インストールした claude を指すよう設定します。

devcontainerなら、devcontainer.json に書けば再構築しても残ります。パスは自分の環境に合わせた例です。

{
  "customizations": {
    "vscode": {
      "settings": {
        "claudeCode.claudeProcessWrapper": "/usr/local/bin/claude"
      }
    }
  }
}

この方法には前提が2つあります。コンテナ内に単体のCLIがインストールされていること(インストール手順はインストールガイド)と、同梱バイナリのパスが引数として渡される点です。今回の症状はバイナリが存在する状況で起きているため、この設定で直るかどうかを示す報告はありません。試すなら、再現しない状態で挙動を確かめてからにすると安全です。

なお、v2.1.133の更新履歴には、同梱バイナリのないビルドで claudeProcessWrapper を指定すると「Unsupported platform」で失敗する不具合の修正が載っています。文言は同じでも、発生条件が別の経路です。報告者の拡張は同梱バイナリを持っていたので、そちらの修正とは関係がないはずです。

3. ターミナルのCLIで作業を続ける

拡張のチャットパネルが使えない間も、コンテナ内のターミナルで claude を実行する経路は別です。拡張は自前のCLIを同梱しているだけで、ターミナル用には別にインストールが要ります。

Claude Dev Container Featureを使うと、Feature側が単体のCLIを入れます。devcontainer.json には次の features ブロックを足します。末尾の :1.0 はFeatureのインストールスクリプトのバージョンで、Claude Codeのリリースを固定するものではありません。

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

コマンドパレットのDev Containers: Rebuild Containerで再構築したら、コンテナ内のターミナルで単体CLIの場所とバージョンを確かめます。

which claude
claude --version

which claude が返したパスは、前の節の claudeCode.claudeProcessWrapper に書くパスとして使えます。例の /usr/local/bin/claude と違う場所なら、そちらに合わせてください。拡張の不調で作業が止まるのを避けたい場合、この経路を先に用意しておけます。

再認証の機会を減らす

この現象は再認証の後に出ています。再認証が起きる回数が減れば、遭遇する回数も減る可能性があります。因果は報告から断定できませんが、コストの低い備えです。

devcontainerの公式ページは、認証情報の保持について次の構成を示しています。~/.claude.json は ~/.claude の外にあるため、ボリュームを ~/.claude に置くだけではサインインが残りません。ボリュームのマウントと CLAUDE_CONFIG_DIR の指定を併用して、.claude.json もボリュームの中に書かせます。報告者の remoteUser は vscode なので、ホームを読み替えると次の形になります。

"mounts": [
  "source=claude-code-config,target=/home/vscode/.claude,type=volume"
],
"containerEnv": {
  "CLAUDE_CONFIG_DIR": "/home/vscode/.claude"
}

プロジェクトごとに状態を分けたいときは、ボリューム名に ${devcontainerId} を含めます。公式の参照構成も claude-code-config-${devcontainerId} を使っています。

ただし、報告者が出会ったのは再構築ではなく「認証が切れたと言われる」場面です。ボリュームは再構築での再ログインを減らす手段で、トークンの期限切れそのものは防げません。この点は期待しすぎないでください。

このissueから言えることと言えないこと

issueはラベルが bug と area:ide で、クローズの理由は無活動です。報告のタイトルや本文にColimaが出てくるのは環境の説明で、Colimaが原因だとは書かれていません。Docker DesktopやRancher Desktopで起きるかどうかについても、記載がありません。

再び遭遇したときの報告に添える情報

クローズされたissueを蒸し返すより、新しいissueを立てるよう案内されています。クローズ時のコメントも同じ内容でした。次の情報があると、原因の絞り込みが進みます。

• 拡張のバージョンと、コンテナ内で見た同梱バイナリの --version
• uname -m、file、ldd --version の出力
• 失敗時のメッセージの全文(短い方と長い方の両方)
• 再認証の直前にホストでColimaやVS Codeを再起動したか、コンテナを再接続したか
• 外向き通信を絞る構成(firewall)を使っているか。使っている場合、認証や拡張の更新が通信の許可漏れで失敗することがあるため、今回の症状と切り分ける材料になります。許可先の設計はinit-firewall.shの記事にあります
• 拡張ディレクトリの内容(ls ~/.vscode-server/extensions/ | grep anthropic)。古い拡張と新しい拡張が並んで残っていないか

拡張ディレクトリの一覧は、更新の途中で複数のバージョンが混在している場合の手がかりになります。報告には 2.1.217 のディレクトリが出てきますが、拡張のバージョンは 2.1.218 と書かれており、一覧を並べれば食い違いの理由が見えるかもしれません。