Claude Codeのworktree isolation checksで拒否される原因と直し方

worktreeで隔離したClaude Codeのセッションでコマンドを流すと、This session is isolated in the worktree /path/to/worktree, but this command … で始まる拒否メッセージが返ることがあります。これは壊れたのではなく、メインチェックアウトを守るための検査が働いた結果です。多くの場合、Claudeがメッセージ末尾の指示どおりにコマンドを書き直して先へ進みます。人が手を入れる必要があるのは、メインチェックアウトを意図して操作したいときくらいです。

読み取り専用の git -C がmainへ向かうケースや、PreToolUseフックやbypassでも通らない理由は、Claude Codeのworktreeはmainへの読み取り専用gitも拒否するで扱っています。ここでは、拒否の3つの理由ごとの書き直し方を扱います。

拒否メッセージはどう読むか

エラーリファレンスでは、この拒否を「Command blocked by the worktree isolation checks」の見出しで扱っています。対象はBash、PowerShell、Monitorの各コマンドで、worktreeに隔離されたセッションの中で実行されたものです。メッセージは必ず is isolated in the worktree <path>, but this command に続けて理由を書きます。

理由は次の3系統です。

3つ目が一番つまずきやすい型です。変数の間接参照 ${!name} や、Bashの関数置換 ${ command; } は、実行時に出てくる値がそれ自体コマンドになり得ます。文面だけではその中身でgitが何をするか確かめられないため、gitに触れないコマンドでも止まります。

エラーリファレンスに載っているメッセージの例は次のとおりです。

This session is isolated in the worktree /path/to/worktree, but this command evaluates ${!x@P} arithmetically inside a construct too complex to verify, which can run a command hidden in a variable's value. Refusing to run it — a worktree-isolated session's git operations must target its own worktree. Split it into plain, separate commands and run them from /path/to/worktree.

末尾の Split it into plain, separate commands and run them from /path/to/worktree. が、そのまま直し方の指示になっています。

理由別の直し方

メッセージはClaudeにツールエラーとして届き、worktreeの名前と進め方が添えられます。理由ごとの対処をまとめると次の形です。

gitの向き先とコマンドの文面については、人が何かをする必要はありません。Claudeがメッセージを読んで書き直すのを待てば足ります。同じ式で何度も拒否され続けるときは、フラグの付いた値をその場で文字どおりに書き、gitは単独のプレーンなコマンドとしてworktreeの内側から実行します。

検証不能な式をプレーンに書き直す

間接参照を使ったコマンドを、値を直接書いた形へ開く例です。変数名は説明用で、実際の式は状況によって違います。

コマンドで表すと、次のような差です(例示であり、特定のセッションで実際に出力された内容ではありません)。

# 拒否されやすい: 変数の間接参照を含む
name=BRANCH; git switch "${!name}"
 
# 通りやすい: 値を直接書き、worktreeの内側で単独実行
git switch feature/login-fix

Claude側の運用として、CLAUDE.md に短い規約を置いておくと拒否の往復が減ります。以下は書き方の一例です。

## worktreeセッションでのgit操作
- gitは worktree 内で素のコマンドとして実行する(`git -C` や `GIT_DIR` を使わない)
- ブランチ名やパスは変数経由にせず、文字どおり書く
- 複数のgit操作は `&&` やサブシェルでつながず、1コマンドずつ実行する

最後の1行は、公式の「plain, separate commands」に沿った書き方です。ただし、どこまで単純にすれば確実に通るかは検査の実装次第で、規約に書いたからといって拒否がゼロになる保証はありません。

検査が見ているもの

エラーの背景は、worktreeのドキュメントの「How Claude Code enforces isolation」節にあります。隔離中のセッションでは4つの検査が働きます。

• ファイル編集: Edit、Write、NotebookEdit が、メインチェックアウト内のパスを対象にしていないか
• コマンドの作業ディレクトリ: Bash、PowerShell、Monitorの実行場所が、メインチェックアウトでないか。メインチェックアウトの外だと確かめられない場合も止まります
• gitのリダイレクト: BashとMonitorで、git -C、--git-dir、GIT_DIR や GIT_WORK_TREE の変数、メインチェックアウトへの cd を経由したgitがないか
• コマンドの形: コマンド名が実行時に決まる、構文を解析できない、${!name} や ${ command; } のような展開がある、といった場合

この4つ目は無効にできません。PowerShellに適用されるのは、作業ディレクトリの検査だけです。

隔離は、--worktree で起動したセッションでも、EnterWorktree で入ったセッションでも、再開したセッションでも同じルールです。セッションから起動するサブエージェントにも同じ検査が及びます。バックグラウンドセッションの隔離の仕組みは、worktree.bgIsolationでバックグラウンド編集を直接許可する仕組みでも扱っています。

検査の外にあるもの

4つの検査が読むのは、編集対象のパス、コマンドを実行するディレクトリ、コマンドの文面の3種類です。シェルコマンドがどのファイルへ書き込むかは追跡しません。そのため、gitをメインチェックアウトで走らせずに書き込む cp やシェルのリダイレクトは、この検査では拒否されません。そうしたコマンドは通常のシェルコマンドと同じく、権限設定とサンドボックスの設定で扱われます。「隔離されているからメインには何も起きない」とは読めない点です。

メインチェックアウトを意図して操作したいとき

メインチェックアウトを操作する用事そのものがある場合、隔離中のセッションからは通りません。エラーリファレンスの対処は、セッションの外の端末で自分で実行することです。

Claudeに回避させる方向ではなく、この線引きを受け入れたほうが、worktreeを使う意味と整合します。

名前の似た別のエラーとの切り分け

worktreeの隔離まわりには、見た目の似たメッセージが他にもあります。どれに当たったかで原因が変わります。

2つ目はファイル書き込みやコマンドの作業ディレクトリのパス綴りの問題で、コマンドの文面とは別の検査です。3つ目はworktreeを隔離先として採用する段階の拒否で、再開時の問題はClaude Codeのworktreeが再利用されるバグとも近い領域です。バックグラウンドセッションで別の理由のコマンド拒否に当たった場合は、「Commands refused」エラーの原因と対処を見てください。

検査はどう厳しくなってきたか

隔離検査は、バージョンを追って細かく調整されています。changelogから、この拒否に関わるものを拾うと次のとおりです。

v2.1.257は拒否を減らす方向、それ以外は取りこぼしを塞ぐ方向の修正です。同じコマンドが、バージョンによって通ったり拒否されたりするのはこのためです。以前は通った式が急に止まるときは、claude --version でバージョンを確かめ、上の時系列と照らすと原因の見当がつきます。

まとめ

拒否メッセージは、読めばほぼ直し方が書いてあります。実行場所をworktreeの内側にそろえ、gitの向き先を指定せず、変数の間接参照のような実行時に決まる式を値の直書きに開くこと。この3点で大半は片付きます。メインチェックアウトを操作する必要があるなら、セッションの外から人が実行するのが筋です。隔離の全体像はClaude Code Worktree実践ガイドにまとまっています。