Claude Codeのpartial cloneでworktreeが作れないときの直し方
worktree作成で「This repository is a partial clone」と出たときの意味と、メッセージ内の手順に沿った直し方。symlinkやGit LFSによる失敗との見分け方も載せています。
claude --worktree が止まり、エラーに This repository is a partial clone と出たときは、リポジトリが部分クローンで、worktreeの起点コミットに必要なgitオブジェクトを取り切れなかったことを意味します。直し方はエラー文の中にあります。try again で終わる一文の手順を実行し、同じシェルから claude --worktree を再実行します。
worktreeの作成が失敗する原因は、部分クローンのほかにsymlinkとGit LFSがあります。エラー文が違うので、見分ければ迷いません。この記事は部分クローンを軸に、3つの条件の見分け方と直し方を1か所にまとめます。
「This repository is a partial clone」は何を言っているか
Claude Codeの公式docsは、このエラーを「worktreeの起点コミットが必要とするgitオブジェクトをすべては取得できなかった」ときのものと説明しています。対処は、メッセージにある try again で終わる一文のステップを取り、それをやった同じシェルで再試行することです。
部分クローンとは、git clone --filter で作るクローンです。gitの公式ドキュメントでは、たとえば --filter=blob:none でファイルの中身(blob)を後回しにし、--filter=blob:limit=<size> で一定サイズ以上のblobを後回しにできます。後回しにされたオブジェクトは、必要になった時点でリモートから取ってくる前提の作りです。
つまり部分クローンのworktreeでは、チェックアウトに要るファイルの中身がローカルに揃っているとは限りません。足りない分をClaude Codeの作成処理が取れなかったときに、このエラーになります。
手順の中身は環境で変わる
公式docsは、エラー文のどの手順を取るかを「メッセージの try again で終わる文」としか指定していません。エラー文が示す手順は環境ごとに異なり、worktreesページのトラブルシューティング節には具体的なコマンドが載っていません。表示された文の手順をそのまま実行します。
同じシェルで再試行する理由も、docsには書かれていません。認証情報や環境変数のようにシェル単位の状態が絡む手順に備えた指定と読めますが、確定した説明ではありません。手順を別のターミナルで済ませたなら、そのターミナルで claude --worktree を実行し直すのが確実です。
再試行のやり方は2通り
docsが挙げる再試行の方法は2つです。
# 手順を実行したシェルで、そのまま作り直す
claude --worktree feature-x
# セッションを開始してから、Claude に頼み直す
claude後者では「worktreeを作って」と改めて頼みます。feature-x は例で、名前は任意です。
部分クローンかどうかを手元で確かめる
エラー文に partial clone と出ていれば確認は要りませんが、「自分のクローンが部分クローンだったのか」を知りたい場合は、gitの設定で分かります。gitの設定リファレンスでは、promisorリモート(後から足りないオブジェクトを渡すと約束するリモート)は remote.<name>.promisor が true、適用したフィルターは remote.<name>.partialclonefilter に入ります。
git config --get remote.origin.promisor
git config --get remote.origin.partialclonefilter前者が true、後者が blob:none のような値なら、git clone --filter=blob:none で作ったクローンです。どちらも空なら部分クローンではないので、エラーの原因は別にあります。リモート名が origin でない場合は読み替えてください。
足りないオブジェクトを数える
どのオブジェクトがローカルに無いかは、git rev-list の --missing=print で一覧にできます。gitのdocsでは「部分クローンの開発を助けるデバッグ用オプション」と位置づけられた機能で、欠けているオブジェクトのIDが ? 付きで出ます。
git rev-list --objects --missing=print HEAD | grep -c '^?'0より大きければ、現在のコミットに必要なオブジェクトが一部ローカルに無い状態です。blob:none のクローンでは、まだ一度も開いていないファイルの数だけ並ぶのが通常で、それ自体は異常ではありません。見る目的は、エラーの前後で数が変わるかどうかです。
3つの失敗条件を見分ける
worktreeの作成失敗は、エラー文の先頭付近でどの条件か判別できます。
| 条件 | エラー文の目印 | 直し方 |
|---|---|---|
| 部分クローン | エラー文の目印This repository is a partial clone | 直し方メッセージの try again で終わる一文の手順を実行し、同じシェルで再試行する |
| symlink | エラー文の目印名前が挙がったパス(.claude・.claude/worktrees・worktreeディレクトリ自体のどれか) | 直し方リンクを外して再試行する |
| Git LFS | エラー文の目印エラーは出ずworktreeは作られる。ただしLFSの管理ファイルがpointerのまま | 直し方worktree内で git lfs pull を実行する |
symlinkは、v2.1.212より前にはコミット済みのリンクを辿ってリポジトリ外にファイルを作る可能性があった経緯があり、現在は作成そのものを拒否します。外し方とパスごとの注意点はworktree作成がsymlinkで失敗するときの解説にまとめています。
Git LFSは、git lfs install --local でフィルターをリポジトリ自身の .git/config に書いているときに起きます。Claude Codeはリポジトリ固有のフィルタードライバーをworktree作成時に実行しない(v2.1.247より前は実行していた)ため、中身が取れずpointerファイルになります。素の git lfs install はグローバル設定なので影響を受けません。
もう1つ紛らわしいのが Refusing to use <path> as an isolation worktree で始まるエラーです。worktreeとして採用する前のgitメタデータの確認で、ディレクトリがメインのチェックアウトに解決されると拒否されます。拒否されたディレクトリには作業が残っている場合があるため、Claude Codeは消さずに残します。読み取れない .git エントリがあるディレクトリも、安全と見なさず拒否されます。メッセージの末尾の文言ごとに復旧手順が分かれます。
worktreeが作れないときの切り分け
- Qエラー文に「This repository is a partial clone」が含まれていますか?答えが次へ答えがはい
メッセージの
try againで終わる一文の手順を実行し、同じシェルで再試行します。 - Qエラーが `.claude` などのシンボリックリンクのパスを名指ししていますか?答えが次へ答えがはい
リンクを外してから再試行します。
- Qエラー文が「Refusing to use ... as an isolation worktree」で始まっていますか?答えが次へ答えがはい
採用前の安全確認で拒否されています。拒否されたディレクトリは残ります。メッセージの末尾の文言に応じた復旧手順を取ります。
worktreeは作られているのに中身が変なとき
LFS管理のファイルがpointerなら、worktree内で git lfs pull を実行します。
変更履歴から読める背景
v2.1.309(2026年10月22日)のchangelogに、関連しそうな変更があります。worktreeの作成と再利用で、gitがオブジェクトをその場で取りにいかなくなったという内容です。対象は通常のクローンと、Bashのsandboxを設定した部分クローンです。後者では、先にオブジェクトを取得してから進む動きになります。
docsのエラー説明とこのchangelogを直接つなぐ記述はありません。ただ、「作成処理が不足オブジェクトをその場で取らない」と「取り切れないときにエラーになる」は同じ方向の話に見えます。古いバージョンで通っていた部分クローンが、更新後に止まるようになった場合は、まずバージョンを確かめてください。
claude --version部分クローンの設定を変えたい場合
remote.<name>.partialclonefilter は、設定を変えても新しいコミットの取得にしか効かないとgitの設定リファレンスにあります。すでにローカルにあるコミットのオブジェクトも取りたいときは、git fetch --refetch を使います。gitのdocsでは、通常の交渉を省いて新規クローンと同様に全オブジェクトを取得するオプションで、フィルター定義が変わったときに再適用する用途とされています。
git fetch --refetchこれは通常の git fetch より転送量が大きくなります。Claude Codeのエラー文が別の手順を示している場合は、そちらを先に実行してください。エラー文の手順が優先です。
部分クローンのまま使い続けるときの運用
エラー対処のほかに、部分クローンでworktreeを使うときの設定上の選択肢があります。
- worktreeの起点を決める: 起点のコミットやsparse checkoutの範囲は設定で指定できる。範囲を絞ると取得すべき対象も絞られる。設定の書き方はworktree.baseRefとsparsePathsの解説にある
- エラー文を控える: 手順の中身は環境で変わるため、
try againを含む一文を控えておくと、同じ環境での2回目以降に迷わない - クラウドへ送るとき:
claude --cloudでも部分クローンは条件つきの扱いになる。仕組みはローカルリポジトリをクラウドに送る仕組みの解説にある
Claude Codeに診断させるなら、次のように頼みます。
worktree作成が「This repository is a partial clone」で失敗した。
git config で remote.origin.promisor と partialclonefilter を確認し、
git rev-list --objects --missing=print HEAD の欠損数を数えて、
エラー文の手順と合わせて次にやることを整理して。実行するのは読み取り専用のgitコマンドだけです。エラー文の手順を実行するのは、結果を見たうえで自分で判断してください。
worktree全般の仕組みや、並列セッションの隔離の考え方はClaude Code Worktree実践ガイドにあります。
まとめ
部分クローンのエラーは、エラー文の try again で終わる一文を実行して、同じシェルから再試行するのが公式の指示です。表示されたエラー文の手順が正です。
手元の状態は remote.origin.promisor と partialclonefilter の2つの設定で確認できます。symlinkならリンクを外し、LFSなら git lfs pull を実行します。エラーが出るかどうかでまず分けると、切り分けが早くなります。