[BUG] Editing ordinary repo files inside .claude/worktrees/<branch>/ triggers the "editing Claude settings" permission guard

Preflight Checklist

• [x] I have searched existing issues and this specific symptom hasn't been reported. Closest related (all about the same .claude/worktrees/ nesting design, but different symptoms): #69026, #60679 (wrong write target), #55902 (closed — allow rules vs. a separate worktree path gate), #63777 (docs).
• [x] This is a single bug report.
• [x] I am using the latest version of Claude Code.

What's wrong?

EnterWorktree (and the documented --worktree flow) creates managed worktrees nested inside the config directory, at <repo>/.claude/worktrees/<branch>/. The permission layer guards writes to .claude/** to protect settings/skills (settings.json, commands/, etc.) — but that guard matches on the .claude/ path prefix, so it also fires on every edit to ordinary repository files that happen to live inside the worktree.

Result: while working in a managed worktree, routine edits to project files (e.g. CONTRIBUTING.md, src/Foo.cs) prompt the user to authorize "editing Claude's settings." The file is not config — it's the user's own repo content in an isolated checkout — but it is indistinguishable from a real .claude/settings.json edit because of the path prefix.

This makes the worktree workflow noisy: the user wants to freely edit anything inside the worktree, but cannot grant that without also relaxing protection on actual Claude config.

Steps to reproduce

1. In a repo, start a managed worktree (via EnterWorktree, --worktree, or a skill that calls EnterWorktree). It lands at <repo>/.claude/worktrees/<branch>/.
2. Have the agent Edit/Write an ordinary, non-config file inside that worktree (e.g. <repo>/.claude/worktrees/<branch>/CONTRIBUTING.md).
3. Observe the permission prompt framing the edit as modifying Claude settings/config.

Expected

Edits to ordinary files inside a managed worktree should be treated as ordinary project edits — governed by normal file-edit permissions for that repo — not as edits to the Claude config directory. The .claude/** settings guard should not match content under .claude/worktrees/.

Actual

Any write under .claude/worktrees/<branch>/ is caught by the .claude/ settings guard and requires authorization as a "settings" edit.

Environment

• Claude Code 2.1.179
• Windows 11 Pro (10.0.26100)

Impact / why it matters

• Constant false-positive prompts during normal worktree work.
• The only obvious mitigations are bad: broaden the allow rule until it also covers real config edits, or stop using managed worktrees.
• Per #55902, allow rules reportedly pass through a separate worktree path gate, so an allow for .claude/worktrees/** may not even suppress this — meaning there may be no clean user-side fix today.

Proposed fixes (either)

1. Exclude .claude/worktrees/ from the settings guard. Treat paths under a managed worktree as ordinary repo paths for permission matching, so only true config paths (.claude/settings*.json, .claude/commands/, .claude/skills/, etc.) trip the guard.
2. Stop nesting managed worktrees under .claude/. Place them outside the config dir (e.g. a sibling <repo>.worktrees/ or a configurable location), which also resolves the adjacent cluster (#69026, #60679) where nested worktree edits leak into the parent checkout. This would benefit from a configurable worktree location (today only worktree.baseRef is exposed; the location is effectively hardcoded).