Worktree isolation denies `Edit` under the base repo's .claude/ — including a separate registered worktree — while `Bash` writes to the same directory are allowed

Status Open
Reported on v2.1.273
Maintainer reply None cached
Activity 0 comments · opened Sep 21, 2026

Summary

Two mismatches, both reproduced on 2.1.273.

  1. Docs vs behaviour. worktrees.md states the rule as blocking an Edit/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.
  2. Tool vs tool. In the same session, at the same moment, Edit to that directory is denied while a Bash write 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

  1. EnterWorktree → session isolated at <base>/.claude/worktrees/isolation-probe
  1. Edit on <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.

  1. In the same session, via Bash: echo probe > <base>/.claude/probe-tmp.txt → succeeds. Reads under <base>/.claude/memory-worktree/ also succeed, as does git fetch there.
  1. ExitWorktree → the same Edit is 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.

View original on GitHub ↗