「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)を使っても回避できません。2026年7月に報告された既知issueで、原因はセッションの外側にあるgitプロキシがpushそのものを認可制にしていることです。

何が起きているか

このエラーは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を直接叩いたときのものです。報告によると、GITHUB_TOKEN環境変数を使ったセッション組み込みの認証もbuiltin injection failedで失敗します。一方でclone・fetch・読み取り系の操作は問題なく通ります。拒否されるのは書き込み(push)だけです。

報告によるとこの挙動は数時間の間に発生し始め(同じセッション内で朝は通っていたpushが午後に失敗するようになった)、以後はセッションを作り直しても再現し続けています。報告者は環境変数にCCR_TEST_GITPROXY=1が入っていたことから、gitプロキシ側の新しい強制ルールがサーバー側でロールアウトされたと推測しています。

個人のPATを使っても効かない理由

Coworkの提供ページは「セッションをクラウド上でリモート実行する(ベータ)」とだけ説明しており、Claude Code on the webと同一の実行基盤かどうかは明記していません。ただしエラー文が案内するドキュメントURLはClaude Code on the webのものです。加えて報告されている環境変数CCR_TEST_GITPROXY CCR_AGENT_PROXY_ENABLED CCR_UPSTREAM_PROXY_ENABLEDから、同じgitプロキシの仕組みを共有している可能性が高いと考えられます。issueの報告者自身も「この設計がCoworkセッションにどう対応するかは不明」と述べています。公式ドキュメントは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資格情報が渡らず、git pushのような書き込み操作は必ずこのプロキシを経由します。プロキシは「このセッションに認可されたリポジトリの集合」を持っていて、集合に入っているリポジトリへのpushだけに自前の資格情報を注入します。報告されている403は、ユーザーが持ち込んだPATを検証して拒否しているのではありません。GitHubに問い合わせる前の段階で、プロキシが「この集合にないリポジトリだから資格情報は注入しない」と判断して止めている状態です。リモートURLにPATを埋め込んでも、プロキシがそのURLへの接続自体を通さなければGitHub側は評価の機会すら持ちません。

claude.ai/codeの「リポジトリセレクター」なら複数リポジトリを認可できる

Claude Code on the webには、この「認可されたリポジトリの集合」を広げる操作が用意されています。claude.ai/codeでセッションを作るとき、入力欄の下にあるリポジトリセレクターから対象を選ぶと、そのリポジトリがセッションの集合に加わります。公式ドキュメントは「複数のリポジトリを追加して1つのセッションの中で横断的に扱える」ともしています。

エラーメッセージが案内するadd_repoというツール名について、公式ドキュメントに独立したページは見当たらず、このリポジトリセレクターの操作と同じものを指すのかは確認できていません。報告者によれば、Cowork(Claude Desktopアプリ)のセッションのサンドボックス内にはadd_repoがPATH上にも、呼び出せるMCPツールとしても存在しないとのことです。

Coworkのタスク作成画面には同じ導線がない

Coworkの「+」ボタンから使える「Add from GitHub」は、この認可済みリポジトリの集合とは別の機能です。こちらはチャットやプロジェクトの参考情報としてリポジトリのファイルを読み込む連携で、ブランチ単位でファイル名と中身を同期するだけの読み取り専用の仕組みです。コミット履歴やPRは取得せず、git pushのような書き込み権限とは関係しません。

報告者によれば、Coworkのデスクトップアプリには、claude.ai/codeのリポジトリセレクターに相当する「このクラウドセッションに書き込み権限を持たせるリポジトリを選ぶ」画面が見当たらないとのことです。エラー文が案内する「セッションのソースにリポジトリを追加する」操作をCowork側から行う手段が示されないまま、pushだけが拒否される状態になっています。

GitHubの接続方法によって最初に入る範囲が変わる

claude.ai/codeでGitHubを接続する方法は2通りあり、それぞれ最初にプロキシへ渡る認可範囲が異なります。

• GitHub App経由: ブラウザでのオンボーディング時にClaude GitHub Appを認可する方法です。公開リポジトリは無条件でクローンでき、非公開リポジトリはAppをインストールした先だけがpushも含めて扱えます。GitHub組織のオーナーがインストールを承認する必要がある場合もあります
• /web-setup経由: ターミナルで/web-setupを実行し、ローカルのghトークンをClaudeアカウントに送る方法です。このトークンが届く範囲のリポジトリはすべて扱えますが、トークンにworkflowスコープが無いと、GitHub Actionsのワークフローファイルを変更するpushだけはGitHub側にも拒否されることがあります

どちらの方法も「アカウント全体としてどこまで触れるか」を決めるだけで、そこからさらに個々のセッションが実際に書き込めるリポジトリを絞り込むのが、今回の「セッションの認可済みリポジトリ集合」です。この集合を広げる操作として公式ドキュメントで確認できるのはリポジトリセレクターだけです。GitHub Appのインストール先を増やす・/web-setupのトークンを発行し直す、といった操作でこの集合が自動的に広がるという記述は見当たりません。

GitHub Appが無いリポジトリはバンドルとしてアップロードされる

claude --cloudを、GitHubのリモートが無い、またはClaude GitHub Appをインストールしていないリポジトリで実行すると、Claude Codeはローカルのリポジトリをまるごとバンドルしてクラウドセッションにアップロードします。これは/web-setupでGitHubを接続済みでも同様です。バンドル由来のセッションは、GitHub接続にそのリポジトリへのpush権限がある場合に限ってGitHubへpushでき、GitHub以外のリモートには一切pushできません。Coworkの「認可済みリポジトリ集合」とは別の制約ですが、pushの可否を切り分けるときは合わせて確認する必要があります。

影響を受ける利用形態の早見表

この状態でできる回避策とできない回避策

• 効かない: PATのスコープを広げる、新しいPATを発行し直す。プロキシはPATの権限を見る前に接続そのものを止めているため、権限の強さは無関係
• 効かない: セッションを作り直す。報告では新規セッション・別コンテナでも同じリポジトリで再現している
• 試す価値がある: pushが必要な変更はCoworkのセッションから直接行わず、claude.ai/code側のリポジトリセレクターで同じリポジトリを選んで新しいセッションを作り、そちらからpushする
• 恒久対応にはならない: GitHub連携(Add from GitHub)を接続し直しても、こちらは読み取り専用の別機能なのでpushの可否には影響しない

Claude Code on the webのクラウドセッションでGitHub連携がどこまで自動化されているかはClaude Codeクラウドセッションで使えるツールとリソース制限に、組織側のネットワークアクセスポリシーやデバイス側のMDM制御はCoworkのMDM管理者設定にまとめています。

よくある質問

GitHub Appをインストールし直せば直りますか

issueの報告範囲では、GitHub Appの再インストールで解消した例は示されていません。GitHub Appのインストールやアクセス権限は、Claude Code on the webがどのリポジトリをクローンできるかを決める設定です。今回のpushエラーが指す「セッションの認可済みリポジトリ集合」とは別の仕組みとして案内されています。インストール範囲を広げる操作がこの集合に自動で反映されるという記述は、公式ドキュメントに見当たりません。

ローカル(Desktopの直接ファイルアクセス)経由ならpushできますか

このissueが報告しているのは「リモートのクラウドサンドボックスセッション」からのpushです。Cowork自体はデスクトップ上でローカルファイルへ直接アクセスする動作もサポートしていますが、gitリポジトリへのpush操作がクラウドセッションを経由せずローカルのgitコマンドだけで完結するかどうかは、公式ドキュメント・issueのどちらにも明記がありません。なお公式ドキュメントには、Desktopアプリの「Continue in」メニューでローカルのターミナルセッションをclaude.ai/codeへ送る機能の記載があります。ただしこれはターミナルセッション向けの機能として案内されており、Coworkのクラウドセッションに同様の経路があるかは確認できていません。

まとめ

Coworkのクラウドセッションでgit pushが「not in this session's authorized repository set」で拒否される場合、原因はPATの権限不足ではなく、gitプロキシが管理する「セッションの認可済みリポジトリ集合」にそのリポジトリが入っていないことです。claude.ai/codeのリポジトリセレクターにはこの集合を広げる操作がありますが、2026年7月の報告時点ではCoworkのデスクトップアプリに同等の導線は見当たりませんでした。issueの報告ではPATの再発行で解消した例は無いため、pushが必要なリポジトリはまずclaude.ai/code側の選択操作を試し、それでも解消しない場合はissueのコメント欄で状況を共有するのが次の一手になります。