Claude Media
claude-code-actionのsetup-bunがGHESで壊れたv1.0.42の不具合と現状
Claude Code解説

claude-code-actionのsetup-bunがGHESで壊れたv1.0.42の不具合と現状

claude-code-action v1.0.42でsetup-bunがGitHub Enterprise Serverで401になる既知の不具合の原因と、現在のmainで再現しない理由をまとめます。

読了目安 約12分

anthropics/claude-code-actionのv1.0.42で、内部でBunをインストールするsetup-bunステップがGitHub Enterprise Server(GHES)環境で401エラーになる不具合が報告されました。issueは2026年2月3日の報告から現在も開いたままで、claude-code-action側で提案された3件の修正案はいずれもマージされていません。ただし現在のmainブランチを実際に調べると、別の理由でこの401は再現しない状態になっています。本記事では発生条件・原因・修正の現状を、ソースコードの差分をもとに扱います。

v1.0.42で何が起きたか

claude-code-actionは実行時にBunランタイムをoven-sh/setup-bunアクションでインストールします。2026年2月1日にマージされた#861は、Bunのリリースタグ取得でAPIレート制限に当たる問題を避けるため、GitHubトークンをsetup-bunへ渡すように変更しました。このパッチが反映されたのがv1.0.42です。

#861が解決しようとしていた問題自体は実在します。GitHub APIは未認証だと1時間あたり60リクエストに制限され、共有ランナーを使う組織では複数ワークフローが同時にBunのリリースタグを取得しようとして頻繁にこの上限へ当たっていました。トークンを渡して認証済みリクエストにすれば、上限は1時間あたり5,000リクエストまで緩和されます。狙い自体は妥当な修正でした。

ところがGHES環境で実行すると、setup-bunステップが401エラーで失敗するようになりました。報告者(ef-trss)によれば、GHESでclaude-code-actionを公式手順どおりにセットアップして実行すると、このステップだけが落ちる状態です。メンテナのpeloyejeも「#861を内部テストしていて気づいたが、マージ前に修正を反映し忘れた」とコメントで認めています。

エラーメッセージと発生条件

issueに添付されたログでは、次のエラーが記録されています。

Error: Error: Failed to fetch url https://api.github.com/repos/oven-sh/bun/git/refs/tags. (status code: 401, status text: Unauthorized)
{
  "message": "Bad credentials",
  "documentation_url": "https://docs.github.com/rest",
  "status": "401"
}

発生条件は次の2点です。

  • GitHub Enterprise Server(または同種のGitHub Enterprise環境)上でワークフローを実行している
  • claude-code-actionのバージョンが、setup-bunへ無条件にトークンを渡すようになったv1.0.42以降である

コメント欄ではuda832がGitHub Enterprise(GHE)でも同じ401が起きることを報告し、actions/create-github-app-tokenで発行したトークンのログにgithub-api-url: https://api.{組織のドメイン}.ghe.com/と表示されていた点を添えています。この値からも、ワークフロー自体はGHES向けの正しいトークンを取得できていたことが分かります。

原因 — setup-bunが常にpublic github.comへリクエストしていた

原因はsetup-bun側の実装にあります。issue発生当時のsetup-bun@v2.1.2のソースを見ると、Bunのバージョン解決処理は次のようになっていました。

async function getSemverDownloadUrl(options: Input): Promise<string> {
  const res = (await (
    await request("https://api.github.com/repos/oven-sh/bun/git/refs/tags", {
      headers: options.token
        ? { "Authorization": `Bearer ${options.token}` }
        : {},
    })
  ).json()) as { ref: string }[];
  // …

bun-versionがv1.3.6のような完全なバージョン文字列でも無条件にhttps://api.github.com/repos/oven-sh/bun/git/refs/tagsへリクエストし、トークンが渡されていればそのままBearerヘッダーに載せていました。claude-code-actionが渡すトークンはGHESインスタンス向けのものなので、public github.comのAPIに対しては無効です。結果として401 Unauthorizedになります。#861自体はAPIレート制限の回避という正当な目的の変更でしたが、リクエスト先が常にpublic github.comに固定されている前提を見落としていました。

claude-code-action側の修正案は3件とも未マージ

issueのコメント欄では、claude-code-action自体を直す修正案が3件提案されていますが、どれもマージされないまま残っています。

PR提案者内容状態
#901提案者peloyeje(メンテナ)内容github.com向けトークンを別入力として分離状態closed(未マージ)
#913提案者外部コントリビュータ内容GHESでのBunインストール手順をFAQに追記するdocsのみの対応状態open(未マージ)
#1001提案者luka5内容oven-sh/setup-bun本体と同じ「public github.com以外では既定トークンを使わない」ロジックへ変更状態open(未マージ)

dr-goo(2026年3月17日のコメント)は「実質的な修正は#913だが、チームがdocs系PRのマージに手が回っていない」と指摘しています。issue #896自体もstate: open、state_reasonなしのまま残っています。

現在のmainブランチでは実際には再現しない

issue自体は開いたままですが、claude-code-actionの現在のaction.ymlを調べると、この401は別の経路で発生しなくなっています。

setup-bunは2026年3月14日にv2.2.0をリリースし、Bunバージョンの解決ロジックに次の分岐を追加しました。

async function getSemverDownloadUrl(options: Input): Promise<string> {
  const { version, os, arch, avx2, profile } = options;
  let tag: string | undefined;
 
  if (validateStrict(version)) {
    tag = `bun-v${version}`;
  }
 
  if (!tag) {
    // ここで初めてrefs/tagsへリクエストする

bun-version入力が完全なセマンティックバージョン(例: 1.3.14)であればvalidateStrict()がtrueを返し、タグを直接組み立ててrefs/tagsへのAPIリクエスト自体をスキップします。トークンを渡すかどうかに関係なく、そもそもGitHub APIを呼ばなくなるため401も起きません。

claude-code-actionは2026年4月20日にマージされた#1238で、setup-bunの参照コミットをこのv2.2.0へ更新しました。目的はNode.js 24対応で、issue #896への直接の対応ではありません。この時点のaction.ymlのbun-versionは1.3.6という完全なバージョン文字列で固定されていましたが、この値がさらに1.3.14へ更新されたのは別コミット#1312(2026年5月14日マージ)によるものです。いずれの版でもbun-versionはワークフロー側から上書きできる入力ではなく、composite action内にハードコードされています。この条件がそろった結果として、setup-bunステップは#1238マージ以降refs/tagsへのリクエストを経由しなくなり、GHES環境でも401が発生しない状態になっています。

つまり、issue #896で提案された3件の修正はどれもマージされていませんが、無関係な目的(Node.js 24対応)での依存先バージョン更新が副産物としてこの401を止めています。GitHubのissueラベルや状態だけを見て「未解決」と判断すると、現在のmain(@v1)では実質的に発生しない事象を過大評価することになります。

それでも押さえておきたい条件

上の説明はあくまで「現在のbun-version: 1.3.14という完全指定と、setup-bun v2.2.0以降の組み合わせではrefs/tagsを呼ばない」という設計に基づく観察です。次のケースでは注意が必要です。

  • 古いclaude-code-actionのパッチバージョンに明示的にピン留めしている場合: @v1.0.42のように#1238より前のコミットへ固定していると、setup-bun側もv2.1.2系のままなので401が再現します。@v1のようなfloatingタグを使っていれば、この更新は自動的に反映されます
  • path_to_bun_executableを使わずBunの自動インストールに依存している場合: この入力を指定するとsetup-bunステップ自体がスキップされるため、そもそも今回の経路に当たりません
  • fork版やカスタムビルドのclaude-code-actionを使っている場合: composite action内のbun-versionをハードコードから変数化していたり、独自にsetup-bunをバージョン範囲(例: ^1.3.0)で呼んでいたりすると、validateStrict()が偽になり再びAPIリクエストの経路を通ります

影響が及ぶのは特定のワークフロー種別に限りません。Bunのインストールはclaude-code-actionのcomposite action内で、Claude Code本体を起動するより前の共通ステップとして実行されるため、interactiveモードのメンション対応・auto-triage・自動コードレビューなど、claude-code-actionを使うワークフロー全種類が対象でした。issueのコメントでもauto-triageとcode-reviewの両方で同じ症状が報告されています。

今から確認できること

自分のワークフローがこの問題の影響範囲に入っていたかどうかは、次の2点で確認できます。

  1. ワークフローファイル(.github/workflows/*.yml)でanthropics/claude-code-actionの行を見て、@v1のようなfloatingタグか、@v1.0.42前後の具体的なパッチバージョンかを確認する
  2. GHES上のActionsタブで、該当ワークフローの実行ログにsetup-bunステップの401エラーが残っていないかをさかのぼって確認する

具体的なパッチバージョンにピン留めしたままGHESで運用している場合は、@v1または#1238以降のコミットへ上げることで解消します。バージョンを固定したくない事情がある場合は、path_to_bun_executable入力でBunの自動インストール自体を回避する方法もあります。GHES上でのClaude Codeの管理者セットアップ全般はGitHub Enterprise ServerでClaude Codeを使うにまとめています。

セルフホストランナーを使っている場合、この401はランナーがapi.github.comへアウトバウンド接続できるかどうかとは無関係な点に注意が必要です。原因はネットワーク到達性ではなく、渡しているトークンの発行元がGHESインスタンス側であることそのものなので、ファイアウォール設定を見直しても解消しません。

まとめ

claude-code-action v1.0.42は、Bunインストール用のsetup-bunステップにGitHubトークンを無条件で渡す変更を含んでおり、GHES環境ではトークンがpublic github.comのAPIに対して無効なため401エラーで失敗していました。claude-code-action自体を直す修正案は3件提案されましたが、いずれも未マージのまま残っています。一方で、無関係な目的でsetup-bunをv2.2.0へ更新した#1238以降は、バージョン解決ロジックの変更によってこの401を引き起こすAPIリクエスト自体が発生しなくなっています。古いパッチバージョンに明示的にピン留めしたままの環境だけが、引き続き対象になります。claude-code-actionの他の既知の不具合と回避策はtsconfig.jsonクラッシュやBedrock認証が壊れた不具合でも扱っています。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →