Claude Codeのworktreeはmainへの読み取り専用gitも拒否する

worktree隔離下のClaude Codeセッションは、git -C <mainのパス>のようにmain checkoutへ明示的にリダイレクトするgitコマンドを、読み取り専用であっても拒否します。PreToolUseフックで手動承認しても結果は変わりません。この挙動はGitHub Issue #84258で報告され、reproducedラベルが付いています。worktreeの隔離範囲そのものの解説はClaude Code Worktree実践ガイドに譲り、本記事はこの特定の拒否パターンに絞って原因と回避策を扱います。

何が起きるか — エラーメッセージと再現条件

報告者の再現手順はこうです。--worktreeまたはEnterWorktreeで隔離セッションを作り、worktree内でコミットを1つ作成したうえで、main checkoutを指す読み取り専用コマンドを実行します。

git -C /absolute/path/to/main/checkout status --short

これだけで拒否されます。実際に返るメッセージは次の内容です。

git merge --ff-onlyのような本来の目的のコマンドでも同じ拒否が返ります。報告者によれば、2.1.221までは同じコマンドが通っており、2.1.222で拒否されるようになったリグレッションです。

原因は4つのチェックのうち「Git redirects」

公式ドキュメントは、worktree隔離中のセッションに4つのチェックが働くと説明しています。

• ファイル編集がmain checkoutを指すときのブロック
• Bash・PowerShell・Monitorの作業ディレクトリがmain checkoutに解決されるときのブロック
• gitをmain checkoutへリダイレクトするコマンドのブロック
• コマンドの中身が静的に検証できないときのブロック

今回の拒否に該当するのは3つ目の「Git redirects」です。ドキュメントは対象になる手口をgit -C・--git-dir・GIT_DIRまたはGIT_WORK_TREE環境変数・main checkoutへのcd後にgitを実行する、の4パターンで列挙しています。このチェックはコマンドが読み取り専用か書き込みかを区別しません。statusのような読み取りコマンドも、mergeのような書き込みコマンドも同じ扱いです。適用範囲はClaude Codeを起動したリポジトリと、そこにリンクされたworktreeが指すmain checkoutの両方に及びます。

PreToolUseで承認しても拒否は解除されない

報告者の環境には、ディレクトリをまたぐBashコマンドを検知して承認を求めるPreToolUseフックが設定されていました。フックはこのgit -Cコマンドを検知してユーザーに確認を求め、ユーザーは承認しました。それでもClaude Codeはハードコードされた拒否メッセージを返し、コマンドを実行しませんでした。

フックが承認してもこのチェックは拒否を返しました。承認結果がチェックに反映されていないことを、Issueは不具合として報告しています。Issueにはbug・documentation・area:permissions・reproducedの4つのラベルが付いています。ドキュメント側では、4つのチェックのうち「Command shape」だけ「無効化する手段はない」と明記されています。一方の「Git redirects」チェックについては、回避策があるとの記載がどこにもありません。

ドキュメントの「共有される」記述との違い

ドキュメントの「What worktrees share with the main checkout」節には、次の記述があります。「worktree内のgitコマンドはメインリポジトリの共有.gitディレクトリに書き込み、sandboxingはその書き込みを許可する。だからgit commitはsandbox有効時でもworktree内から問題なく動く」。

この記述自体は正確です。worktree内で完結するgit commitやgit logは、-Cのような明示的なリダイレクトを伴わないため、Git redirectsチェックの対象になりません。矛盾するように見えるのは、Issueが引用する2.1.222のchangelog文言のほうです。「main checkoutに対する破壊的なgitコマンドを実行できてしまう問題を修正した」とあり、対象を「破壊的な」操作に限定するように読めます。しかし実際のチェックはstatusのような読み取り専用コマンドも区別なく拒否するため、changelogの文言と実装の対象範囲にはずれがあります。

バージョンの変遷とIssueの現在地

worktree隔離とgitリダイレクトの扱いは、直近のバージョンで次のように変わってきました。

v2.1.222のリリース全体はClaude Code v2.1.222 — worktree分離をセッション本体まで拡張にまとめています。今回の拒否は、このリリースがサブエージェント限定だった保護をセッション本体に広げた結果として表面化しました。「全セッション種別」にはバックグラウンドセッションも含まれ、その隔離既定値はworktree.bgIsolationでバックグラウンド編集を直接許可する仕組みで扱っています。

Issue #84258は2026-08-05の登録以降openのままで、reproducedラベルが付いています。2.1.270時点のchangelogにも、git -Cリダイレクトの読み取り専用コマンドを許可する側への修正は見当たりません。

今できる回避策

git -Cによるmain checkoutへの明示的なリダイレクトそのものを無効化する設定は、ドキュメント・Issueのどちらにも記載がありません。実務で取れる選択肢は次の3つです。

1つ目は、worktree自身の中で完結させることです。main checkoutを指す代わりに、worktreeのディレクトリでコマンドを実行すればチェックの対象外になります。ただしこれはmainへのマージ自体を代替する方法ではありません。

2つ目は、ExitWorktreeでセッションをmain checkoutへ戻してから操作する方法です。ドキュメントは4つのチェックを「セッションがworktreeに隔離されている間」働くものと説明しています。隔離を抜ければ、チェック自体が働かなくなります。ただし報告者はこの方法を避けたい理由も挙げています。

• mainが他のセッションで先に進んでいると、戻った直後のマージが失敗して再度worktreeへ戻る手戻りが発生することがある
• 作業を継続したい場合に不便
• worktreeを手動で削除する手間が生じる

3つ目は、Claude Codeのツール呼び出しを経由しない方法です。このチェックはClaude Code自身が実行するBash・Monitorツール呼び出しに対するものであり、ユーザーが別のターミナルで直接git -Cやマージコマンドを実行することは制限の対象外です。Claude Codeのツール呼び出しの外で行う、という選択肢になります。

いずれも代替であって正式な解決策ではありません。報告者はIssueで、worktreeセッションからmain checkoutへブランチをマージして完了させるサポートされた方法自体が現状存在しないと指摘しています。

よくある質問

PowerShellコマンドでも同じ拒否が起きますか

起きません。ドキュメントはPowerShellコマンドについて、4つのチェックのうち作業ディレクトリのチェックだけが適用されると明記しています。Git redirectsチェックの対象はBashまたはMonitorのコマンドです。

サブエージェントも同じ制限を受けますか

受けます。隔離されたセッションから生成されたサブエージェントすべてに、同じ4つのチェックが及びます。バックグラウンドで動くセッションでも対話セッションでも変わりません。

まとめ

worktree隔離下のセッションがmain checkoutへgit -Cでリダイレクトすると、読み取り専用のコマンドでもPreToolUse承認後でも拒否されます。原因は4つのチェックのうち「Git redirects」で、PreToolUseフックで承認しても拒否は変わりません。v2.1.222でサブエージェントだけでなくセッション本体にも適用が広がったことで表面化した挙動で、Issue #84258にはreproducedラベルが付いています。Issueはopenのままで、2.1.270時点のchangelogにも修正は見当たりません。回避策を使うなら、worktree内で完結させるか、ExitWorktreeで隔離を抜けるか、Claude Codeのツール呼び出しを経由せず別ターミナルで実行するかの3択になります。PreToolUseフックの仕組み自体はPreToolUse hookでツール実行前に許可・拒否・改変するにまとめています。