マルチエージェントの worktree 隔離 データ毀損リスク自己診断

サブエージェントを isolation: worktree で並列に走らせる運用で、隔離が黙って無効になり、コミットが意図しないブランチへ静かに着地する事故への露出を、5問で測ります。答えは送信されません。採点は全てこのページの中だけで動きます。 English.

この型がなぜ怖いか。 報告されている事例では、先行したサブエージェントの worktree が孤立した後、親(lead)セッションの作業ディレクトリが .claude/worktrees/ 配下に残ってしまう。次にサブエージェントを起動すると「すでに worktree の中にいる」と誤判定されて隔離がスキップされ、サブエージェントが親の作業コピー(別ブランチの作業中の変更)を直接編集してコミットを積む。エラーも警告も出ず、後のリベースや force push で初めて、変更が違うブランチに着地していたと分かる、という流れだそうです。普段こまめに git を使う人ほど「コミットしたから安全」と思い込みやすく、防御が原理的に効きにくい盲点だと報告されています。

1. サブエージェントを isolation: worktree で並列に走らせていますか

2. 親セッションの作業ディレクトリが .claude/worktrees/ の配下に残っていないか、確認する習慣がありますか

3. サブエージェントのコミットが、意図しないブランチに着地していた経験はありますか

4. ファイルへの書き込みが、いまいるリポジトリの worktree の外へ出ていないかを、実行の前に止める仕組み(PreToolUse のガード)を入れていますか

5. 並列のサブエージェントが同じファイルを同時に編集して、互いの変更を踏み潰す可能性に備えていますか

この診断は、報告されている事例(anthropics/claude-code#70456=隔離が黙って無効になり in-place 編集に堕ちる型、#70069=worktree のルートでなくリポジトリのルートにパスが解決される型)をもとにしています。これらは私の直接の体験でなく、起票で共有された報告です。一方、対策として挙げる worktree-escape-write-guard.sh は cc-safe-setup に実装され、回帰試験を通したガードです。採点はあなたのブラウザの中だけで動き、答えは収集も送信もしません。recommendations は出発点で、各環境での検証の代わりにはなりません。