Read auto-accept writes rules with doubled leading slash; broad allow-rule doesn't match linked-worktree paths

Resolved 💬 3 comments Opened Apr 28, 2026 by w-goog Closed Apr 28, 2026

Description

A Read(/Users/me/code/**) rule at the user level does not match Read calls targeting paths inside a linked git worktree that lives outside the cwd repo, even though the path is lexically a subpath of the rule.

When I "always allow" the prompt, Claude Code writes the auto-generated rule to settings.local.json with a doubled leading slash:

"Read(//Users/me/code/tasks/codegen/<branch>/**)"

The doubled // suggests path normalization is concatenating "/" + already-absolute path. The single-slash rule never matches that internal representation.

Repro

  1. In user settings.json, allow "Read(/Users/me/code/**)".
  2. cwd is /Users/me/code/repo-A (a regular git checkout).
  3. git worktree add /Users/me/code/tasks/codegen/branch-x … (peer to repo-A).
  4. Have Claude Code Read a file under /Users/me/code/tasks/codegen/branch-x/….

Expected: Read is allowed by the existing rule.
Observed: Prompt; on "always allow", a rule with the doubled-slash form gets written into <repo-A>/.claude/settings.local.json.

Workaround

Add a parallel doubled-slash rule to user settings:

"Read(//Users/me/code/**)"

Environment

  • Claude Code 2.1.122
  • macOS Darwin 25.4.0

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗