[Bug] Worktree Edit guard incorrectly blocks files in nested git repos and suggests non-existent paths

Bug Description
Title: Worktree Edit guard blocks files in nested git repos under the base checkout and suggests a path that doesn't exist Versions: Claude desktop app 2.26454.0 (Code tab), Claude Code 2.1.289, macOS 27.0.1, git 2.55.0 Setup ~/Projects is a git repo used as a parent folder. It is deny-by-default and tracks only CLAUDE.md and .gitignore. It contains about 20 independent git repos, each with its own .git and remote (e.g. ~/Projects/gridiron, ~/Projects/chart-terminal). They are not submodules and are not tracked by the parent. The Code tab session runs in a worktree of the parent: ~/Projects/.claude/worktrees/<name> (worktree location setting: "Inside the project"). Steps to reproduce Open a Code tab session on ~/Projects, so it gets a worktree. Ask Claude to edit a file in a nested repo, e.g. ~/Projects/gridiron/deploy/serve.py. What happens The Edit tool is blocked with: PreToolUse:Edit hook error: This session is running in an isolated git worktree at ~/Projects/.claude/worktrees/<name>, but ~/Projects/gridiron/deploy/serve.py is in the base repo checkout. Edits there do not land on this session's branch and may corrupt the user's primary working copy. Use the worktree path instead: ~/Projects/.claude/worktrees/<name>/gridiron/deploy/serve.py Why this is wrong The file isn't part of the base repo's working copy. git -C ~/Projects/gridiron rev-parse --show-toplevel returns ~/Projects/gridiron, a different repository. The suggested path doesn't exist. The parent repo doesn't track gridiron/, so the worktree has no copy of it. Following the advice can't work either way. A file created at the suggested path would never reach the gridiron repo or the service running from it. The guard can't be configured, so the agent's only options are to give up or route the edit through Bash, which defeats the point of the guard. Expected The guard should not treat a path as "in the base repo checkout" when a nearer git repository contains it: there is a .git between the base repo root and the target, and that repo's top level is not the base repo. In that case it should allow the edit, or at most warn, since the edit lands in that repo's own working copy. Two possible fixes: Before blocking, walk up from the target to the base repo root and allow the edit if any directory on the way has its own .git (folder or file). Or allow the edit when the target is git-ignored by the base repo. Workaround in use: opening a session directly on the nested repo's folder avoids the guard. Within a parent-folder session, the edit has to go through Bash.

Environment Info

• Platform: darwin
• Terminal: Apple_Terminal
• Version: 2.1.173
• Feedback ID: 895b1fe7-23e5-412f-b7cb-38c26bf1b998

Errors

[]