Worktree isolation denies `Edit` under the base repo's .claude/ — including a separate registered worktree — while `Bash` writes to the same directory are allowed
Summary
Two mismatches, both reproduced on 2.1.273.
- Docs vs behaviour.
worktrees.mdstates the rule as blocking anEdit/Write/NotebookEdit"that targets a path in the main checkout." The implementation also denies paths under<base>/.claude/**when that path is a different, registered git worktree — not the main checkout. - Tool vs tool. In the same session, at the same moment,
Editto that directory is denied while aBashwrite to the same directory succeeds.
Environment
- Claude Code 2.1.273, Windows 11, git 2.55.0.windows.2, desktop app
Setup
A second worktree holds auto-memory and is registered normally:
$ git worktree list
C:/Users/<user>/proj [main]
C:/Users/<user>/proj/.claude/memory-worktree [memory]
Reproduction
EnterWorktree→ session isolated at<base>/.claude/worktrees/isolation-probe
Editon<base>/.claude/memory-worktree/.claude/memory/<file>.md→
> This session is isolated in the worktree <base>\.claude\worktrees\isolation-probe. Edit the worktree copy of this file instead of the shared-checkout path.
The target is not the main checkout. It is its own worktree on its own branch, and it has no "worktree copy" — the suggested remedy does not exist for this path.
- In the same session, via
Bash:echo probe > <base>/.claude/probe-tmp.txt→ succeeds. Reads under<base>/.claude/memory-worktree/also succeed, as doesgit fetchthere.
ExitWorktree→ the sameEditis no longer denied.
An earlier run on a 2.1.2xx build produced a differently-worded denial for the same action, carrying toolDenialKind: "permission-rule":
... but <path> is in the base repo's shared .claude/ directory. Edit the worktree's own .claude/ instead, or run that change from a non-worktree session.
Why this matters
The guard blocks the audited, reviewable tool and leaves the shell path open, so it does not actually isolate the directory — it only redirects the agent to the less inspectable route. Setups that route file edits through Bash by configuration are unaffected by the guard entirely, while Edit users hit a refusal whose suggested remedy ("edit the worktree copy") has no meaning for a path that is itself a separate worktree.
Expected
Either the two tools agree on the path, or the docs describe the actual .claude/** rule and the refusal names a remedy that exists for separate-worktree targets.