claude --cloudとCCR_FORCE_BUNDLE — GitHub未接続のリポジトリを送る仕組み

GitHubにつながっていなくてもclaude --cloudは動く

claude --cloud は、通常ならGitHubのremoteをクラウドVMでcloneしてセッションを始めます。git remoteが無いリポジトリや、Claude GitHub Appが入っていないgithub.comのリポジトリでは、別の経路に切り替わります。手元のリポジトリをバンドルにまとめ、そのままクラウドセッションへアップロードする経路です。/web-setup でGitHubを接続済みでも、この切り替えは起きます。

つまり、GitHubに置いていない社内リポジトリや、まだremoteを張っていない作りかけのリポジトリでも、クラウドセッションに仕事を渡せます。ただし、このときのアップロードには「何が含まれ、何が除かれるか」「OSによって扱いが違う」という癖があります。送る前に確認できる項目を順に見ます。

--cloud の基本的な使い方はClaude Codeのクラウド・モバイル利用ガイドにあります。ここでは、バンドル経路だけを掘り下げます。

バンドルに含まれるものと含まれないもの

バンドルの中身は、次のとおりです。

通常のGitHub経由のcloneは、pushしたブランチの状態しか見えません。バンドル経路は、未コミットの変更まで届く点が違います。

一方で、未追跡ファイルは入りません。新しく作ったばかりでまだ git add していないファイルは、クラウド側に存在しないまま始まります。Claudeに新規ファイルを前提にした作業をさせるなら、先に git add します。

機密ファイルの扱いはOSで分かれる

未コミット変更の送り方は、プラットフォームで異なります。ここが、この仕組みでいちばん見落としやすい点です。

macOS・Linux・WSLで除外の対象になるのは、認証情報や鍵のような名前のファイルです。.env、Terraformの *.tfvars、id_rsa や *.pem などの鍵ファイルが挙がっています。加えて、Git LFSのようなgitフィルターが管理するファイルの未コミット変更も除外されます。除外されたファイルは、セッション開始時にコミット済みの版が置かれます。コミット済みの版が無ければ、そのファイルは無い状態で始まります。

ネイティブWindowsでは、この除外がありません。追跡ファイルの未コミット変更は、名前に関わらずそのままアップロードされます。送りたくない編集があるなら、git stash で退避するか、いったん元に戻してから --cloud を実行します。

除外されるのは「追跡済みで、未コミットの変更」だけ

この除外ルールの射程は、広く読みすぎないほうが安全です。バンドルは未追跡ファイルを含めないため、.gitignore に入れた .env はそもそも送られません。除外ルールが働くのは、すでに追跡されている .env や鍵ファイルに、コミットしていない編集があるときです。

逆に言えば、機密ファイルを誤ってコミットしてしまっていた場合、その履歴は全ブランチ分のバンドルに入ります。除外ルールが守るのは未コミットの編集であって、過去のコミットに入った中身ではありません。履歴に秘密情報が残っていないかは、送る前に別途確かめます。

CCR_FORCE_BUNDLE=1でGitHub上のリポジトリもバンドルで送る

バンドルが使われるのは、通常は、remoteが無い場合かGitHub Appが未導入の場合です。remoteから普通にcloneできる状況でも、あえてバンドルで送りたいときは環境変数 CCR_FORCE_BUNDLE=1 を付けます。

CCR_FORCE_BUNDLE=1 claude --cloud "Run the test suite and fix any failures"

この変数が効く場面は、主に2つあります。

• GitLabやBitbucketなど、GitHub以外のリポジトリを送る: クラウドセッションのリポジトリclone・PR作成はGitHub前提なので、GitHub以外のremoteは通常の経路に乗りません。CCR_FORCE_BUNDLE=1 を付ければ、ローカルバンドルとして送れます。
• pushしていない状態を、そのまま渡す: remoteにpushせずに、手元の履歴と未コミット変更をまとめて渡したいとき。

GitLabなどの扱いで注意したいのは、セッションから元のremoteへ結果をpushで返せない点です。クラウドで進めた変更は、claude.ai上のセッションで確認する前提で進めます。GitHub連携の側にpush権限がある場合に限り、バンドル由来のセッションからGitHubのremoteへpushできます。

GitLab側のMRとの紐付けで別の問題に当たったときは、Claude DesktopでGitLabのMRが紐付かない場合の原因も参考になります。

送る前に満たす条件と、送れないときのエラー

バンドルには条件があります。満たさないとセッションは始まりません。

• ディレクトリがgitリポジトリで、コミットが1つ以上あること
• バンドルが100MB未満であること。超えると現在のブランチだけのバンドルに、それでも大きければ作業ツリーを1枚にまとめたスナップショットに縮み、そこでも収まらなければ失敗する
• 未追跡ファイルは含まれないため、必要なファイルは git add しておくこと
• macOS・Linux・WSLでは、git 2.31以降であること

送る前の確認は、次のコマンドで足ります。

git --version                  # 2.31 以降か
git status --short             # 未追跡(??)と未コミット変更を確認
git log --oneline -1           # コミットが 1 つ以上あるか
git count-objects -vH          # size-pack: 履歴の大きさの目安

git count-objects の数字は、バンドルのサイズそのものではなく目安です。100MBに近いなら、GitHubへpushしてClaude GitHub Appを入れ、通常のclone経路を使うほうが制限を避けられます。

Not uploading this working tree: が出る原因

macOS・Linux・WSLでは、アップロード前にチェックが走ります。条件を満たさないとClaude Codeはセッションを始めず、Not uploading this working tree: を含むエラーを出して原因と直し方を示します。原因として挙がっているのは、次のようなものです。

core.attributesFile がincludeされた設定ファイルの中にある、といった場合も、アップロードは拒否されます。gitが保存前にファイルを変換する設定(clean filterで暗号化するなど)を追いきれず、変換前の中身が上がってしまう恐れがあるためです。拒否時のメッセージは設定名と直し方を示すので、その最後の一文のとおりに設定行を移します。

部分cloneは条件つきで通ります。git clone --filter で作ったものは、追跡ファイルがすべて手元にあれば、履歴なしの作業ツリーのスナップショットとして上がります。

送り方の判断:バンドルで送るか、GitHubにpushするか

どの経路になるかは、次の順で確かめると迷いません。

通常のclone経路でクラウドVMが取得するのは、今いるディレクトリのGitHub remoteの、今いるブランチです。手元のチェックアウトそのものではありません。plan modeで計画を立ててからクラウドに渡す使い方でも、計画をリポジトリに保存し、commitしてpushしておくと、VMが同じ計画を読めます。バンドルで送るなら、このpushは要りません。

クラウドセッションそのものの制約はClaude Codeクラウドセッションの使えるツールと制限、VMの中身はClaude Code Webのクラウド環境の仕組みで扱っています。