今週のClaude Code。「隔離されているはず」のworktreeが、実は親リポジトリに書き込めていた

何が起きたか

公式チェンジログのv2.1.224（2026年8月7日）には、次の修正が記載されています。まず、isolation: 'worktree'を指定したサブエージェントが、隔離された作業ツリーの外にある親リポジトリに対して破壊的なgit操作を実行できてしまう不具合が修正されました。あわせて、この修正はすべてのセッション種別のファイル編集とBash実行に隔離を適用する形へ強化されています。

同じバージョンには、権限チェックのバイパス系の修正が3件並んでいます。1つ目はPreToolUseフックが自動モードの権限チェックを回避できていた問題、2つ目はサマリー生成や圧縮、リネームといったバックグラウンドのエージェントタスクに権限制限が適用されていなかった問題です。3つ目はSandbox機能側で、denyRead: "~/.aws/"のようにパスの末尾にスラッシュを付けた拒否設定が、LinuxとmacOSでバイパスされてしまう不具合でした。これらはいずれも、設定上は制限されているはずの操作が、特定の条件で素通りしていたという点で共通しています。

翌8日リリースのv2.1.225では、claude agentsコマンドに、信頼されていないディレクトリを開く際のワークスペース信頼プロンプトが追加されています。通常のclaudeコマンドではすでにあった確認ステップを、別の起動経路にも揃えた形です。

実務にどう効くか

当メディアの運営元は、複数のサブエージェントを並列で走らせる業務フローを日常的に使っており、ファイルを書き換える作業を隔離環境に任せる場面が少なくありません。worktree分離は「サブエージェントが本体のリポジトリを壊さない」という前提そのものを支える機能であるため、その前提が一部の操作で崩れていたという今回の修正は、隔離を信頼して並列実行を組んでいる運用ほど影響が大きくなります。

確認すべき点は、隔離を使ったサブエージェント実行で「取り消しの利かない操作（既存ブランチの削除、force pushに類する操作など）」を任せている箇所がないかどうかです。今回の修正が入る前のバージョンでこうした運用をしていた場合、隔離が効いていなかった期間に何が起きていたかを、リポジトリの履歴から遡って確認しておく価値があります。バージョンを更新した後も、隔離モードを使う設計そのものを過信せず、破壊的な操作は最終的に人が承認するフローを重ねておくのが安全です。

PreToolUseフックやバックグラウンドタスクの権限バイパスについても同様です。フックや権限設定を「安全装置」として運用している場合、装置自体に穴があった以上、その装置だけに頼らない多重の確認体制を組んでおくことが、今回のような修正が今後また入る可能性への備えになります。

編集部の見立て

今回まとまって修正された項目は、機能追加ではなく「効いているはずの制限が効いていなかった」という種類の不具合です。新機能の不具合であれば使わなければ影響を受けませんが、隔離や権限チェックのように安全性の前提として使っている機能にこの種の不具合が見つかると、気づかないまま運用していた期間の影響を遡って考える必要が出てきます。バージョンアップの案内を追うだけでなく、隔離や権限まわりの修正が入ったときは、自分たちの運用がその機能を安全装置として過信していないかを定期的に見直す習慣が要りそうです。

次号予告は購読でお知らせします。