「authorized repository set」エラーでCoworkのgit pushが拒否される

Coworkのクラウドセッションからgit pushすると、access denied by the git proxy: <owner>/<repo> is not in this session's authorized repository setという403で止まることがあります。自分のGitHub個人アクセストークン(PAT)を埋め込んでも結果は同じです。

原因はセッションの外にあるgitプロキシです。2026年8月17日にAnthropicの担当者がissueで「意図した挙動」と回答しており、バグとしての修正は来ません。紐づけ操作を各画面で自分で行えるようにする改善は、検討中と回答されています。

何が起きているか

このエラーはGitHub issue #76248で2026年7月10日に報告されました。報告者はCowork(Claude Desktopアプリ)からクラウドのサンドボックスセッションを起動し、fine-grainedのPAT(Contents読み書き権限あり)をリモートURLに埋め込んでgit pushしています。

返ってきたエラーは次の2種類です。

remote: access denied by the git proxy: <owner>/<repo> is not in this session's authorized repository set, so the proxy will not inject a credential for it. To fix, add the repository to the session's sources.
fatal: unable to access 'https://github.com/<owner>/<repo>.git/': The requested URL returned error: 403

{"message":"GitHub access to this repository is not enabled for this session. Use add_repo to request access.","documentation_url":"https://docs.anthropic.com/en/docs/claude-code/github-actions"}

前者はpush時、後者は同じPATでapi.github.comのREST APIを直接叩いたときのものです。clone・fetchなどの読み取りは通り、拒否されるのは書き込みだけでした。

報告者は、同じセッションで朝は通ったpushが数時間後に失敗し始めたこと、環境変数にCCR_TEST_GITPROXY=1が入っていたことから、サーバー側で新しい強制ルールが配られたと見ています。

Anthropicの回答は「意図した挙動」

2026年8月17日、issueにAnthropicのBoris Cherny氏が回答を付けています。クラウドセッションを再現したうえで、読み取りは通るが、セッションに設定されたソース以外への書き込みはgitプロキシが403で拒否し、URLに埋め込んだPATも同じ拒否になると確認しました。

結論は次の2点です。

• 意図した挙動である。資格情報はサンドボックスの外に置かれ、セッションのリポジトリに絞ったプロキシが注入する。持ち込みの資格情報を通さないのは、この隔離モデルの一部
• 現時点の回避策は、pushが必要なリポジトリをセッション作成時にすべて含めること(例: そのリポジトリからセッションを始める)

Claude Code on the webのドキュメントも同じ設計を説明しています。

in Anthropic-hosted environments, git credentials and signing keys stay outside the sandbox, and a proxy authenticates on the session's behalf with scoped credentials (Anthropicがホストする環境では、gitの資格情報と署名鍵はサンドボックスの外に置かれ、プロキシがセッションの代わりにスコープ済みの資格情報で認証する)

プロキシの仕様ページには、リポジトリの範囲についても書かれています。GitHub APIとリリースアセットへのリクエストは、セッションに紐づいたリポジトリにしか届きません。セットアップスクリプトが未接続のリポジトリからリリースアセットを取ろうとすると403になります。さらにブランチの削除と、タグなどブランチ以外へのpushもプロキシが拒否します。

手元のセッションで何が原因かを切り分ける

同じ403でも、セッションの種類と作り方で打ち手が変わります。上から順に確認してください。

Coworkに紐づけ操作が無いという報告

エラーはadd_repoを使うか、セッションのソースにリポジトリを足すよう案内します。Anthropic側も、Cowork(デスクトップ)のセッションからそれを行う見つけやすい手段が今はないと認めています。

issueのコメントでは、次のような報告が続いています。

• 設定の「Connectors」「Claude Code」「Cowork」のどこにも、リポジトリを紐づける画面が無い
• タスクの開始前にClaudeへリポジトリの選択を頼んでも、実際に選べる操作が無い
• モバイルアプリから始めたCoworkセッションにも、リポジトリを選ぶ画面が無い
• add_repoはサンドボックス内のPATHにもMCPツール一覧にも無い
• add_repoの承認ダイアログが出て承認しても、次の呼び出しでセッションの範囲が広がっていなかった

claude.ai/codeにはリポジトリセレクターがあり、Claude CodeのWeb版では入力欄の下から対象を選びます。公式ドキュメントも、複数のリポジトリを追加して1つのセッションで横断的に扱えると書いています。つまり、リポジトリを紐づけるための操作が確実にあるのはclaude.aiのコードタブ側です。

チャット画面の「+」ボタンにある「Add from GitHub」は別機能です。サポート記事では、チャットやプロジェクトのナレッジとして、ファイルやフォルダを選んで読み込む連携として説明されています。同期されるのは特定ブランチのファイルの名前と内容だけで、コミット履歴やPRなどのメタデータは取得されません。クラウドセッションの認可集合を広げる操作ではありません。

GitHubコネクタ経由のpushで報告されている限界

Coworkにリポジトリを紐づけられないとき、セッション内のGitHubコネクタで書き込みを続けた報告があります。ただし、その道にも別の限界が出ています。

• ファイルを1つずつ丸ごと再アップロードする方式のため、4ファイル・114行の修正で約40回のツール呼び出しになり、そのうち約25回がpushだった例がある。1つの67KBのファイルを変更するために、サブエージェントにファイル全体を打ち直させた例もある
• ファイル全体を1回のツール呼び出しの引数に載せる設計のため、サイズが大きいと送れない。369,363バイトのpackage-lock.jsonは、1回の応答で出せる量を超えて切り詰められ、コミットできなかったという測定がある
• テキスト内のエスケープ文字列がpush時にデコードされ、ブロブの内容とサイズがずれた例がある

ここまでの内容はすべてissueのコメントでの報告であり、Anthropicの公式な仕様説明ではありません。ロックファイルや大きなファイルを含む変更は、この方法では送りにくいようです。

ローカル実行なら通るが、2026年10月6日からPro・Maxは選べなくなる

報告者の1人は、デスクトップ版Coworkでタスクを自分のコンピューター上で実行したセッションで、同じリポジトリ・同じPATのclone、commit、pushが通ったと書いています。CCR_TEST_GITPROXYなどのプロキシ用環境変数も、そのセッションにはありませんでした。ローカルのClaude Code CLIから同じアカウントでpushが通ったという報告もあります。

しかし、この道には期限があります。Coworkのサポート記事によると、2026年10月6日から、ProとMaxプランの新規Coworkタスクはクラウドで動きます。設定の「一般」にある「コンピュータのみ」のオプションは削除されます。スケジュール済みタスクもクラウドに移動します。issueには、予定タスクのpushが止まったという2026年8月5日の報告があります。すでにコンピューター上で始めたタスクはそのまま続けられ、そのタスクの上部にトランスクリプトを保存するボタンが出ます。

サポート記事の10月6日の変更は、ProとMaxプランについての告知です。クラウドとローカルのどちらで動いているかの見分け方はCoworkのクラウド実行とローカル実行を見分ける方法にあります。issueのコメントには、Coworkでやっていた作業をClaude Codeへ移したところ、速度も流れも良くなったという報告が1件あります。

GitHubの接続方法ごとに、最初に入る範囲が違う

claude.ai/codeでGitHubを接続する方法は2通りで、プロキシに渡る最初の範囲が変わります。

/web-setupのトークンにworkflowスコープが無いと、GitHub Actionsのワークフローファイルを変えるpushなどが、GitHub側で拒否されることがあります。これはプロキシの認可集合とは別の話です。

プロジェクトのスレッドは、どちらの方法で接続しても、クローンするリポジトリごとにClaude GitHub Appのインストールが必要です。

手元のリポジトリをバンドルでアップロードした場合

次のどちらかのリポジトリでclaude --cloudを実行すると、Claude Codeは手元のリポジトリをバンドルにしてクラウドセッションへ直接アップロードします。対象は、gitのリモートが無いリポジトリと、Claude GitHub Appを入れていないgithub.comのリポジトリです。/web-setupでGitHubを接続済みでも同様です。

バンドル由来のセッションは、GitHub接続にそのリポジトリへのpush権限がある場合に限ってGitHubへpushできます。GitHub以外のリモートにはpushできません。環境変数CCR_FORCE_BUNDLE=1で、GitHubのリポジトリでも強制的にバンドル方式にできます。GitLabやBitbucketのリポジトリもこの変数でクラウドセッションへ送れますが、結果をそのリモートへpushすることはできません。

実機のClaude Code v2.1.287では、claude --helpにこのクラウド実行の入口が出ます。

--cloud [description|session_id|url]  Create a cloud session with the given
                                      description, or attach to an existing
                                      one by session ID or claude.ai/code URL

この問題の経緯

よくある質問

GitHub Appを入れ直せば直りますか

Appの再インストールやConnectorsでの再接続でも直らなかった報告があります。ある報告者は、ClaudeのGitHub Appをすべてのリポジトリに読み書き権限付きで入れても、その後に開いたセッションで同じ拒否が続いたと書いています。

一方、別のコメントは、claude-github-mcp-connectorのインストール画面から再接続が必要だったと書いています。公式の説明では、GitHub Appはクラウドセッションがクローンとpushで届くリポジトリの範囲を決める接続方法です。Appを入れ直しても、そのセッションに紐づいていないリポジトリへのpushは、プロキシが止めます。

まとめ

CoworkのクラウドセッションでpushがPATの権限と無関係に403になるなら、リポジトリがセッションに紐づいていないことが原因です。pushが必要な作業は、リポジトリを選んでセッションを始められるclaude.aiのコードタブか、手元のClaude Codeで進める形になります。ProとMaxでは10月6日以降、Coworkでローカル実行に頼る逃げ道が新規タスクでは使えなくなります。