plugin_marketplacesでバイナリが配置されない原因と対処 — claude-code-action
claude-code-action@v1でplugin_marketplacesを設定すると、claude installが成功表示のままバイナリを配置しないことがあります。原因と回避策をまとめます。
plugin_marketplacesで何が起きるか
anthropics/claude-code-action@v1にplugin_marketplacesを設定したGitHub Actionsワークフローが、claude installのログでは成功表示なのに、その直後のマーケットプレース追加でENOENTエラーになる既知の問題があります。ログには次のように表示されます。
⚠ Setup notes:
● installMethod is native, but directory /home/runner/.local/bin does not exist
● installMethod is native, but claude command not found at /home/runner/.local/bin/claude
✔ Claude Code successfully installed!
Version: 2.1.129
Location: ~/.local/bin/claudesuccessfully installedと表示された直後に、次のエラーで停止します。
Action failed with error: Failed to add marketplace '...': ENOENT: no such file or directory, posix_spawn '/home/runner/.local/bin/claude'インストーラーは警告を出しながらも終了コード0を返し、続く✔ Claude Code successfully installed!の表示は、実際にはバイナリが配置されていない状態のまま出ています。issueの起票者はこれを「ログの表示自体が誤解を招く(misleading)」と説明しています。
原因はインストーラー側とaction側の両方にある
原因は1つの不具合ではなく、2つの見落としが重なって表面化します。
1つ目は、ネイティブインストーラー(curl -fsSL https://claude.ai/install.sh | bash)の側です。公式のセットアップ手順では、macOS・Linuxのネイティブインストールは~/.local/bin/claudeにランチャーをシンボリックリンクとして配置し、実体は~/.local/share/claude/versions/配下に置く方式を取っています。/home/runner/.local/binのような配置先ディレクトリが存在しない環境では、このシンボリックリンク作成の段階が失敗しているにもかかわらず、インストーラー全体としては終了コード0を返す挙動になっています。
2つ目は、claude-code-action本体の側です。issueの指摘によると、src/entrypoints/run.ts内のinstallClaudeCode()はインストーラーの終了コードを無条件に信頼し、${HOME}/.local/bin/claudeというパスをそのまま返す実装になっています。返されたパスはinstallPlugins()・addMarketplace()に渡され、実体のないファイルへposix_spawnしようとしてENOENTになります。
この2つ目の問題はplugin_marketplaces固有ではありません。コメント欄では、plugin_marketplacesもpluginsも設定しないワークフローでも同じ警告ログが出ることが報告されています。この場合マーケットプレースの処理自体はスキップされるため、失敗するタイミングが後ろにずれ、SDK起動時に次のエラーとして表面化します。
SDK execution error: ReferenceError: Claude Code native binary not found at /home/runner/.local/bin/claude.
Please ensure Claude Code is installed via native installer or
specify a valid path with options.pathToClaudeCodeExecutable.つまりplugin_marketplacesを外すだけの対処は、失敗する場所をaddMarketplace()からSDK実行時へ移すだけで、根本原因(バイナリが実際には配置されていない)は解消していません。プロンプト実行だけのシンプルな構成でも、SDK経由でClaude Codeを起動する限り同じ地雷を踏みます。GitHub Actions組み込みの基本構成そのものはClaude CodeをGitHub Actionsに組み込むにまとめています。
issueの起票者は修正の方向性を2つ提案しています。1つはインストーラー側で、配置先ディレクトリが存在しないなら作成する、または配置できない場合に終了コードを0以外にするという案。もう1つはaction側で、返す前にfs.existsSync(claudePath)のようなチェックを入れ、存在しなければ例外を投げるという案です。前者はClaude Code本体のリポジトリ側の変更が必要になる一方、後者はclaude-code-actionだけで完結するため、実際に出た2件の修正PRはいずれも後者の方向で書かれています。
表面化から現在までの経緯
この不具合は一度きりの発生ではなく、複数のタイミングで再発が報告されています。
| 日付 | 出来事 |
|---|---|
| 2026-05-06 02:20 UTC | 出来事直前の実行は成功(Claude Code 2.1.129、警告なし) |
| 2026-05-06 05:38 UTC | 出来事同じactionのSHA・同じランナーイメージで初めて失敗(警告ログが出現) |
| 2026-05-06 06:17 UTC | 出来事issue #1290が起票される |
| 2026-05-06 08:07 UTC | 出来事mkdir -p ~/.local/binを事前実行する回避策が共有される |
| 2026-05-06 11:14 UTC | 出来事「解決したようだ」というコメントが付く(公式な修正の告知ではない) |
| 2026-05-23〜24 | 出来事修正PR #1346がオープンされるが、mergeされずクローズ |
| 2026-08-26 | 出来事別の報告者が再発を確認。同一ランナーイメージでの3回の試行のうち、Claude Code 2.1.243を引いた2回は失敗、2.1.241を引いた1回は成功という記録が残る |
| 2026-08-29〜09-12 | 出来事2件目の修正PR #1754がオープンされるが、こちらもmergeされずクローズ |
5月6日時点の「解決したようだ」というコメントは同日中の主観的な観察で、実際には8月下旬に別のClaude Codeバージョンで再発しています。8月の報告では、同じワークフロー・同じランナーイメージのまま数分違いで3回実行し、インストールされたバージョンが2.1.243か2.1.241かだけが結果を分けたと記録されています。ランナーやワークフロー設定ではなく、ネイティブインストーラー側のリリースごとの挙動差が原因である可能性を裏づける観察です。当日中には、regression前のaction側コミット(2cc1ac1)へ一時的にピン留めして凌いだという報告もありますが、install.sh自体はバージョン引数なしで最新を取得する実装のため、この種のピン留めが恒久的な回避になる保証はありません。
確認されている範囲
コメント欄に集まった報告は、いずれもGitHub-hosted runnerのubuntu-24.04イメージで、複数の無関係なリポジトリにまたがっています。認証方式はclaude_code_oauth_tokenによるOAuth認証と、明記のない構成の両方が含まれ、認証方式による違いは報告されていません。issueのスレッドには、セルフホストランナーやmacOS・Windowsランナーでの再現報告は見当たりません。GitHub-hosted Ubuntu以外の環境で同じ症状が出るかどうかは、この一次情報からは判断できません。
今すぐ使える回避策
修正の取り込みを待たずに使える回避策は2つあります。
1. ~/.local/binを事前に作成する
actionを実行するステップより前に、ディレクトリを作成しておく方法です。
- name: Create Claude Code install directory
run: mkdir -p ~/.local/bin
- name: Run Claude Code
uses: anthropics/claude-code-action@v1配置先が存在している状態にすれば、ネイティブインストーラーはシンボリックリンクを正常に作成できます。ただしこれは根本原因(インストーラーがディレクトリの欠落以外の理由で失敗するケース)まではカバーしない、コミュニティ発の暫定対応です。
2. バージョンを固定したバイナリをpath_to_claude_code_executableで指定する
action.ymlで定義されているpath_to_claude_code_executableは、カスタムのClaude Code実行ファイルを指定すると自動インストールをスキップする公式入力です。公式のインストール手順にはバージョンを指定するインストール方法も用意されているため、この2つを組み合わせると、action自身のインストール処理を経由せずに済みます。ただし原因は配置先ディレクトリの欠落なので、事前インストール側でもmkdir -pとバイナリの実在確認を省くと、エラーを出さずに失敗する同じ状態を踏みます。
- name: Install a pinned Claude Code version
run: |
mkdir -p ~/.local/bin
curl -fsSL https://claude.ai/install.sh | bash -s 2.1.241
test -x ~/.local/bin/claude
- uses: anthropics/claude-code-action@v1
with:
path_to_claude_code_executable: /home/runner/.local/bin/claude
claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}test -xを入れているのは、インストーラーが警告付きで終了コード0を返す実装だからです。ここで実在確認をしておかないと、後続のpath_to_claude_code_executableが存在しないパスを指すだけになり、この不具合と同じく、エラーが表に出ないまま失敗する状態を自分で作ることになります。ここでの2.1.241は、8月の再発報告で失敗しなかった組み合わせの一例にすぎず、特定のバージョンを推奨しているわけではありません。action内部のインストール処理は、バージョン引数を渡さずにinstall.shを呼び出しており、常に最新リリースを取得する実装だとissueで指摘されています。バージョンを指定したインストールをワークフロー側で明示的に済ませておけば、actionが未検証のまま新しいバイナリを取得する経路自体を避けられます。
構成別の影響
同じ不具合でも、ワークフローの構成によって症状の出方と回避のしやすさが変わります。
| 構成 | 影響 | 理由 |
|---|---|---|
plugin_marketplacesを設定 | 影響明確な影響あり | 理由addMarketplace()が即座にENOENTで失敗し、ワークフロー全体が止まる |
plugin_marketplacesなし・通常のprompt実行 | 影響影響あり(気づきにくい) | 理由失敗がSDK起動時まで遅延し、エラーメッセージも異なるため原因特定に時間がかかる |
path_to_claude_code_executableで事前インストール済みバイナリを指定済み | 影響ほぼ影響なし | 理由action自身のインストール処理を経由しないため、この不具合の経路に入らない |
セルフホストランナーで~/.local/binを永続化している | 影響報告なし(未確認) | 理由issueに再現報告がなく判断できない |
修正PRは2件とも取り込まれていない
この不具合に対する修正の提案は2回出ていますが、いずれもmergeされていません。1回目は2026年5月23日に開かれたPR #1346で、installClaudeCode()にバイナリの存在確認を追加する内容でしたが翌日クローズされました。2回目は2026年8月29日に開かれたPR #1754で、同様にexistsSync()によるチェックを追加し、失敗時のエラーメッセージでpath_to_claude_code_executableの利用を案内する内容でしたが、こちらも9月12日にmergeされずクローズされています。issue #1290自体はクローズされておらず、追跡は続いています。
2件とも「インストーラーの終了コードを信頼せず、返す前にバイナリの実在を確認する」という同じ方向の修正です。2回目の提案が1回目のクローズから3か月後に、しかも一度は収束したかに見えた5月の報告から独立した経路(2.1.243と2.1.241というバージョン差)で再発した後に出てきている点は、この問題がaction単体の一度きりの不具合ではなく、アップストリームのネイティブインストーラーのリリースごとに繰り返し起こりうる構造だという見方を裏づけます。
よくあるつまずき
plugin_marketplacesを外して直ったように見えてもnative binary not foundのログが無いか確認する: このエラー文字列が出ていれば、addMarketplace()からSDK起動時へ失敗箇所が移動しただけの可能性があります- actionのバージョンをSHA固定しても、内部でインストールされるClaude Codeのバージョンは固定されません:
install.shはバージョン引数なしで呼ばれ常に最新を取得する実装だとissueで報告されているため、action側のピン留めとバイナリのピン留めは別物です mkdir -p ~/.local/binはランナーごとの暫定対応: GitHub-hosted runnerは実行のたびに使い捨てられるため、この回避策はワークフロー内の該当ステップに毎回含める必要があります。セルフホストランナーでの挙動については、issueのスレッドに再現報告が見当たらず判断できませんpath_to_claude_code_executableを指定しているのにエラーが出る場合: 指定したパスにバイナリが実際に存在するかをランナー上で確認してください。事前インストールのステップが別のジョブ・別のランナーで実行されていると、パスだけ渡してもファイルは存在しません- 失敗時のCIログが読みにくい: SDK実行エラーの直前に、圧縮されたバンドルのソースが数KB分そのままログへ出力されるという報告があります。本来のエラーメッセージを探すときは、ログの末尾側から遡って確認すると見つけやすくなります
まとめ
plugin_marketplaces設定時に起きる「claude installは成功表示なのにバイナリが配置されない」問題は、ネイティブインストーラーが警告付きで終了コード0を返す挙動と、claude-code-actionがその終了コードを無条件に信頼する実装が重なって起きています。plugin_marketplacesを使っていないワークフローでも、SDK起動時に同じ根本原因が別のエラーとして現れます。修正PRは2026年5月と8月の2回提案されましたが、いずれもmergeされずクローズされ、issue自体は追跡が続いています。取り込みを待つ間は、~/.local/binの事前作成か、バージョンを固定したバイナリをpath_to_claude_code_executableで指定する方法のいずれかで回避できます。GitHub Actions上で似た症状に遭遇した別の不具合として、allowed_non_write_users設定時にBashコマンドが全滅する問題がClaude Code v2.1.227で修正されています。ローカル環境でnpmインストール時に出るnative binary not installedは原因が異なり、native binary not installedエラーの原因と対処で扱っています。