Five questions → how exposed are you to the failure where isolation: worktree silently turns off and a sub-agent's commits land on the wrong branch? Your answers are never sent anywhere — all scoring runs in your browser.日本語版.
Why this one is dangerous. In the reported cases, after an earlier sub-agent's worktree is stranded, the lead session's working directory is left under .claude/worktrees/. When the next sub-agent spawns, the guard reportedly mistakes this for "already inside a worktree," skips isolation, and the sub-agent edits the lead's working copy (the in-progress changes of a different branch) directly and commits there. No error, no warning. You only find out later — on a rebase or a force-push — that the commits landed on the wrong branch. The operators who keep committing frequently are the ones most likely to assume "I committed, so I'm safe," which is exactly why this blind spot is hard to catch.
1. Do you run sub-agents in parallel with isolation: worktree?
2. Do you check that the lead session's working directory hasn't been left under .claude/worktrees/?
3. Have you ever found a sub-agent's commits had landed on a branch you didn't intend?
4. Do you have a PreToolUse guard that stops writes from escaping the current repo's worktree before they execute?
5. Are you protected against parallel sub-agents editing the same file and clobbering each other?
This self-check is based on reported cases — anthropics/claude-code#70456 (isolation silently disabled, falls back to in-place edits) and #70069 (paths resolved against the repo root instead of the worktree root). These are not my own experience — they are reports shared on the tracker. The mitigation I point to, worktree-escape-write-guard.sh, is a guard implemented in cc-safe-setup with regression tests. Scoring runs entirely in your browser; answers are not collected or transmitted. The recommendations are pointers, not a substitute for verifying behavior in your own setup.