claude-code-actionがOIDC交換後にRepository not foundで落ちる

claude-code-actionのログにApp token successfully obtainedと出たあとでremote: Repository not found.が続き、git fetch origin mainで止まる。2026年10月27日の朝(UTC)から、private repositoryのPRでこの失敗が複数の利用者から報告されています。ワークフローは変えていないのに、前日まで通っていたレビュー用のジョブが全PRで落ちる形です。

報告はGitHubのIssue #1935にまとまっています。原因はIssueの中で特定されておらず、ラベルはbug・p1・area:permissions・provider:1pです。この記事では、報告された症状、ログのどこで何が起きているか、似た別のエラーとの見分け方、手元でできる切り分けを順に書きます。

どんな失敗が起きているのか

失敗するのは、アクションがOIDCトークンをGitHub App用のトークンに交換し、その直後にPRのベースブランチを取得するステップです。ログは次の順に流れます。

Exchanging OIDC token for app token...
App token successfully obtained
...
Restoring .claude, .mcp.json, .claude.json, .gitmodules, .ripgreprc, CLAUDE.md, CLAUDE.local.md, .husky from origin/main (PR head is untrusted)
remote: Repository not found.
fatal: repository 'https://github.com/<org>/<repo>.git/' not found
##[error]Action failed with error: Command failed: git fetch origin main --depth=1 --no-recurse-submodules

トークンの取得自体は成功しています。落ちるのはその後のgit fetchです。メッセージは「権限がない」ではなく「リポジトリが見つからない」で、トークンがこのリポジトリを見られない状態を示しています。

Issueの報告をまとめると、共通点は次のとおりです。

• 対象はprivate repositoryで、組織のリポジトリと個人アカウントのリポジトリの両方で出ている
• 同じジョブ内のactions/checkoutはGITHUB_TOKENで同じリポジトリを問題なく取得できる
• 再実行しても同じ場所で失敗する
• ワークフロー、設定、デフォルトブランチのどれにも変更を入れていない

「ログがどの行まで同じか」は切り分けの手がかりになります。ある報告者は、失敗した実行と直後に成功した再実行のログがgit fetchの直前まで1行ずつ一致していたと書いています。差が出るのは取得したトークンの中身だけ、という見立てができます。

発生した時間帯と影響範囲

Issueに書かれた時刻をUTCでそろえると、次の流れになります。

同じ組織の中でも、通るリポジトリと落ちるリポジトリが混在している点が目立ちます。起票者は2つのprivateリポジトリで全PRが失敗し、3つ目では成功しました。別の報告者は、最初の失敗の2分後の再実行が一度成功し、そのあとはすべて失敗したと書いています。時刻やリポジトリによって結果が変わるため、ワークフローの書き方よりトークンの側に原因がありそうに見えます。ただしこれは報告からの推測で、Issueには原因の説明がありません。

どのバージョンでも起きている

報告されたバージョンは複数あります。

v1.0.134からv1.0.259まで同じ症状が出ているので、アクションのバージョンを上げても下げても避けられるとは言えません。uses:をコミットSHA(8041f1d)で固定した報告でも失敗しています。失敗するgit fetchのコマンドは--depth=1が付く場合と付かない場合がありますが、Repository not found.で止まる点は変わりません。

RESTは通るのにgit fetchだけ落ちる

個人アカウントのリポジトリで出た報告に、手がかりになる観察があります。PRに進捗コメントが作られ、そのあとclaude[bot]が「Claude encountered an error」に更新する、というものです。同じトークンでコメントの作成と更新はできています。拒否されているのはgitの取得だけで、REST APIは通っています。別の報告者も、進捗コメントは投稿できてgit fetchだけが失敗すると書いています。

これが何を意味するかは、Issueの中では分かっていません。起票者は、Claude GitHub Appに全リポジトリでcontents: writeが付いていることを確認したうえで、「交換で発行されたトークンに、07:10 UTC以降どのリポジトリとどの権限が載ったかを確認してほしい」と運営側に依頼しています。トークンに載る権限の確認は、利用者側からはできない作業です。

なぜベースブランチを取得するのか

失敗するステップは、アクションが意図して行っています。アクションのセキュリティ文書によると、PRに対して動くとき、Claudeを起動する前に次のパスをPRのベースブランチから復元します。

• .claude/
• .mcp.json
• .claude.json
• .gitmodules
• .ripgreprc
• CLAUDE.md
• CLAUDE.local.md
• .husky/

ベースブランチに存在しないパスは削除され、PRが持ち込んだ版は.claude-pr/に参照用として残ります。PRの作者がCLAUDE.mdやフックを書き換えても、そのままClaudeに読ませないための仕組みです。

ログの(PR head is untrusted)はこの意味です。ベースブランチの取得は、PRを処理するたびに通る道なので、ここが落ちると全PRが失敗します。

似たエラーとの見分け方

OIDCまわりの失敗は他にもあります。ログの文言で原因が分かれるので、まず見分けます。

Exchanging OIDC token for app token...の前で止まるなら、本記事の件ではなくid-token: writeの欠落を疑います。App token successfully obtainedが出たあとのgit fetchで止まる場合に限り、Issue #1935と同じ症状です。

手元で切り分ける

自分のリポジトリが同じ症状か確かめる手順です。GitHub CLIがあれば、ワークフローの実行履歴から最後の成功と最初の失敗を並べられます。

# 直近20回の結果と開始時刻を出す(ファイル名は自分のものに置き換える)
gh run list --workflow claude-review.yml --limit 20 \
  --json databaseId,conclusion,createdAt,event
 
# 失敗した実行のログから該当行だけ拾う
gh run view <run-id> --log-failed \
  | grep -n -e "App token" -e "Repository not found" -e "git fetch"

最後の成功時刻と最初の失敗時刻を控え、Issueの時間帯(2026年10月27日の05:59〜07:55 UTC)と重なるかを見ます。重なっていて、ログにApp token successfully obtainedとRepository not found.が並ぶなら、同じ症状と考えてよいでしょう。createdAtはUTCで出るので、時差の換算も要りません。

利用者側の対処は限られる

Issueには運営側の回答が書かれておらず、確立した回避策もありません。ワークフロー側でできることを、副作用つきで挙げます。

再実行で様子を見る

再実行が通ったのは1例で、別の報告者の最初の失敗の2分後に一度だけ成功しました。別リポジトリでは、起票者の3つ目のリポジトリが同じワークフローで07:17に成功しています。さらに、08:06 UTC以降は何も変えずに復旧したという報告もあります。再実行、別リポジトリ、自然復旧は別々の話で、復旧を待つだけで済む可能性はあっても確約ではありません。起票者の2リポジトリは07:50にも失敗し、別の報告者は2回の再実行がどちらも落ちたと書いています。

チェックを赤にしないようにする

レビュー用のジョブが必須チェックに入っていると、障害のあいだPRがマージできなくなります。一時的に外すなら、ステップにcontinue-on-error: trueを付ける方法があります。ただし失敗してもジョブが緑になるので、レビューが走っていないことに気づきにくくなります。止めている間は、PRのコメント欄でclaude[bot]が「Claude encountered an error」に更新していないかを見る運用が要ります。

- uses: anthropics/claude-code-action@v1
  continue-on-error: true
  with:
    claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}

github_tokenを渡す構成は別物

FAQは、GitHub Appを使わない場合にgithub_tokenを入力として渡せると説明しています。入力表では「自分で用意したカスタムGitHub Appをつなぐときだけ指定する」入力です。渡すとコメントはclaude[bot]ではなく、そのトークンのユーザー名で投稿されます。スティッキーコメントもclaude[bot]前提なので、更新されなくなります。

GitHub Actionsの文書には、ワークロードアイデンティティ連携の節で、github_tokenを自分で渡す場合にも連携の交換のためにid-token: writeが要る、と書かれています。github_tokenにGITHUB_TOKENを渡せばこの失敗を避けられるかどうかは、Issueでは誰も試していません。試す場合は、投稿者名が変わることと、権限がpermissionsの範囲に限られることを承知のうえで、テスト用のブランチで確かめることになります。

導入を見直すときに押さえる点

障害とは別に、構成の前提を確認しておくと、次に似た症状が出たときに切り分けが速くなります。

1. Claude GitHub Appが対象リポジトリにインストールされ、停止されていないか。インストール手順はClaude GitHub Appのインストール手順にあります
2. 組織全体に入れている場合、「All repositories」か選択リストか。選択リストなら対象に載っているか。組織での導入はClaude CodeのGitHub Actionsを組織全体に導入する手順が扱っています
3. permissionsにid-token: writeがあるか
4. 認証がclaude_code_oauth_tokenかanthropic_api_keyか

今回の報告の一つでは、Appは「All repositories」でcontents: writeが付いており、停止もされていませんでした。この点が正常でも落ちているので、Appの設定画面を確かめて異常が無いときは、利用者側でできることはほぼ尽きています。アクション全体の入力とclaude_argsの渡し方はGitHub Actionsのパラメータとclaude_argsの渡し方に、OIDCの扱いを含む全体像はClaude CodeをGitHub Actionsに組み込む手順にあります。

Issueの追い方

追跡先はIssue #1935です。10月27日の08:28 UTCのコメントを最後に更新が止まっており、運営側の返信は書かれていません。Issueはopenのままで、ラベルはbug・p1・area:permissions・provider:1pです。報告者は、リポジトリ名や実行IDを非公開で共有する用意があると書いています。自分の環境でも再現するなら、実行ログのうちApp token successfully obtainedからRepository not found.までの行、アクションのバージョン、ベースブランチ名、失敗の開始時刻(UTC)を添えて報告すると、原因の絞り込みに使えます。リポジトリ名は伏せて構いません。

まとめ

App token successfully obtainedの直後にRepository not found.で止まる失敗は、id-token: writeの欠落やワークフローの書き間違いとは別物です。2026年10月27日の朝にはv1.0.134〜v1.0.259のどれでも出ており、同じ組織内でも通るリポジトリと落ちるリポジトリがありました。報告から言えるのは、トークンの発行は成功すること、RESTでのコメント投稿は通ること、git fetchだけが拒否されることの3点です。

利用者側でできるのは、症状の一致を確かめること、再実行で通るかを見ること、必須チェックから一時的に外すことまでです。github_tokenを渡す構成は投稿者名やスティッキーコメントに影響する別の認証経路で、この障害の回避になると確認された手段ではありません。