Not uploading this working treeでクラウド送信が止まる原因と対処

claude --cloudを実行すると、クラウドセッションが始まる前にNot uploading this working tree: core.ignoreCase ...で止まることがあります。別の形では、Could not upload repo bundle (...)に続けてThe GitHub App preflight failed transientlyと出て終わります。前者は設定を直すと通り、後者はまず再実行が正解です。見た目は似ていても、直す場所が違います。

2つのエラーは何を意味するか

どちらも、手元のリポジトリをクラウドへ送る「バンドルのアップロード」の周辺で出ます。バンドルは、リポジトリ履歴と追跡ファイルの未コミット変更をまとめて送る仕組みです。

バンドルが使われるのは、リモートのないリポジトリか、Claude GitHub Appが入っていないgithub.comのリポジトリでclaude --cloudを実行したときです。/web-setupでGitHubを接続していても同じです。CCR_FORCE_BUNDLE=1を付けると、cloneできる場合でも強制的にバンドルを送ります。GitHub側の認証方式の違いはGitHub AppとWeb setupの選び方にあります。

core.ignoreCaseを理由に拒否されたとき

メッセージの全文は次のとおりです。

Not uploading this working tree: core.ignoreCase (which decides whether .gitattributes patterns match file names regardless of letter case) is set in <file>, and the upload cannot follow that setting, so a file git would change before storing it (to encrypt it, for example) could be uploaded as it is on disk. Move the core.ignoreCase line into this repository's .git/config or directly into your ~/.gitconfig, then retry.

なぜ拒否されるのか

core.ignoreCaseは、.gitattributesのパターンがファイル名の大文字小文字を無視して一致するかを決めます。アップロード側がこの設定を再現できないと、どの属性ルールがどのファイルに当たるかを取り違えるおそれがあります。

取り違えると、gitが保存前に変換するファイルが、ディスク上の状態のまま送られかねません。公式の例は、cleanフィルターで暗号化するファイルです。そこでClaude Codeは、ルールの漏れを許さずアップロードごと止めます。何も送られていないので、失敗した時点で中身が漏れる心配はありません。

直し方

メッセージ中の<file>に、設定が書かれたファイルが出ます。その行を次のどちらかへ移します。

• このリポジトリの.git/config
• ~/.gitconfigに直接書く

どこで効いているかは、手元でも確かめられます。

git config --show-origin --get-all core.ignorecase
git config --show-origin --get-all core.attributesfile

--show-originはエラーが指す設定の出どころを表示します。core.ignorecaseの大文字小文字はgitが区別しないため、小文字で問題ありません。出力のファイルパスが、.git/configと~/.gitconfigのどちらでもなければ、そこが移し替え対象です。

includeの先でも拒否される

見落としやすい点が1つあります。メッセージが指すのは、gitの設定がincludeやincludeIfで取り込む別ファイルのことがあります。しかも、そのincludeIfの条件がこのリポジトリに当てはまらなくても、ファイル名が出る場合があります。

同じ拒否はほかの設定でも出る

公式は、同じ拒否がcore.attributesFileとattr.treeでも出ると説明しています。それぞれに固有の直し方がメッセージ末尾に付くので、core.ignoreCaseの手順を機械的に当てはめず、最後の1文に従います。on the webの説明には、core.attributesFileをincludeされた設定ファイルに置いた場合が例に挙がっています。

この拒否が起きるのはmacOS、Linux、WSLです。ネイティブWindowsでは、アップロード前のこの種の確認自体を行いません。

「Not uploading this working tree」の別の原因

同じ接頭辞のエラーは、core.ignoreCase以外でも出ます。公式がまとめている原因は次の4つです。メッセージには原因と変更点が書かれるので、まず本文を読みます。

gitのバージョンは次で確認できます。

git --version
git rev-parse --git-dir --git-common-dir

2つ目のコマンドで、--git-dirと--git-common-dirが別の場所を指していれば、リンクworktreeにいる可能性があります。ただしこの出力だけでは、sparse checkoutの設定があるかまでは分かりません。

ここまでの原因はすべて、アップロードが「正しく再現できない」と判断した場合の拒否です。バンドルの上限による失敗とは別物で、後者は履歴が大きいときに現在のブランチだけ、さらにワーキングツリーのスナップショット1枚へと段階的に縮め、それでも大きければ失敗します。上限は100MBです。

GitHub App preflightが一時的に失敗したとき

こちらは設定ミスではないことが多いエラーです。全文は次の形です。

Could not upload repo bundle (<error>). The GitHub App preflight failed transiently (network or service hiccup) — retry in a moment to start from GitHub instead

2つの失敗が同時に起きている

文は前半と後半に分かれます。前半のCould not upload repo bundle (<error>)は、バンドルを作れなかった、または送れなかったことを示します。後半は、アップロードの前に行った「クラウド側がGitHubからこのリポジトリをcloneできるか」の確認が、確定回答を得られず終わったことを示します。確認の失敗は、ネットワークエラー、タイムアウト、一時的なサーバーエラーのように、再試行で消える種類です。

直し方は再実行、続くなら前半を見る

• しばらく待ってコマンドを再実行します。GitHub側の確認が通れば、Claude Codeは失敗したアップロードに頼らず、GitHubのcloneからセッションを始められます
• 再実行しても失敗が続くなら、メッセージの先頭に出ている<error>が、アップロードを止めた原因です。直せる原因なら直すと、手元のリポジトリから始められます

つまり、このエラーで「GitHubを設定し直す」必要はありません。以前のバージョンでは、文末がPlease set up GitHub on https://claude.ai/codeでした。v2.1.251より前は、確認が一時的に失敗しただけでもこの案内が出ており、設定を直しても一時的な失敗は消えません。この文言が出る古いバージョンを使っているなら、案内に従う前に更新を考えます。

似た見た目の別エラーと取り違えない

GitHubが接続されていない場合は、別のメッセージになります。GitHub isn't connected to your Claude account, so this repository can't be cloned in the cloud.で始まり、/web-setupを実行するか、claude.ai/connect-githubから接続するよう促されます。公式によると、v2.1.268より前はこの状態も「Claude GitHub Appの一時的な失敗」として報告され、再試行やApp導入が提案されていました。どちらも接続の解決にはなりません。古いバージョンでpreflightの一時失敗が繰り返し出るなら、GitHub接続の有無を疑う価値があります。

どこから切り分けるか

メッセージの文言で、取る行動が分かれます。

アップロードを避けるという選択肢

claude --cloudで送るリポジトリがGitHub上にあるなら、アップロードと、その要件そのものを避けられます。ブランチをpushし、リポジトリにClaude GitHub Appを入れてから、もう一度セッションを開始します。クラウドのVMは、手元のチェックアウトではなくGitHubのリモートの現在のブランチをcloneします。未pushのコミットは届かないので、先にpushします。

一方、バンドル経由で始めたセッションは、GitHubのリモートへpushできるかどうかが、接続のpush権限に依存します。GitLabやBitbucketのリポジトリは、CCR_FORCE_BUNDLE=1でバンドルとして送れますが、結果をそのリモートへpushし返すことはできません。

また、バンドルは追跡されていないファイルを含みません。クラウドに見せたいファイルはgit addしておきます。macOS、Linux、WSLでは、.env、*.tfvars、id_rsa、*.pemのような機密に見えるファイルの未コミット変更と、Git LFSなどのフィルターが管理するファイルの未コミット変更も、アップロードから外れます。外れたファイルはLeft on this machine:の通知に並びます。

ultrareviewでも同じ拒否が出る

core.ignoreCaseの拒否は、クラウドセッション用のアップロードだけでなく、ブランチを送るultrareviewでも出ます。/code-review ultraで止まったときも、メッセージの最後の文に従って設定を直します。ultrareview自体の使い方はultrareviewの実行手順にあります。

クラウドセッションの動かし方はクラウドセッションを並列で回すに、クラウドとローカルの行き来はteleportの使い方にまとめています。