[Bug] Permission inheritance not re-resolved when worktree created after main-tree work

Bug Description
Title: Mid-session worktree creation doesn't re-resolve permissions; inheritance depends on whether main-tree work happened first Summary: When EnterWorktree creates a worktree after the session has already done work in the main checkout, committed permission allow-rules stop applying inside the worktree. The same rules apply correctly if the worktree is created before any main-tree work. Environment: Claude Agent view (background-agent). .claude/settings.local.json is committed (tracked, not gitignored) and contains "Bash(git )", "Bash(git commit)". Repro: - A (correct): New session → immediately ask to implement a feature → worktree created → git commit auto-allowed. - B (bug): New session → ask a question first (agent reads files in the main tree) → then ask to implement → worktree created → git commit now prompts for permission, despite the worktree containing the committed settings.local.json that allows it. Expected: Permission resolution should be identical regardless of whether main-tree reads preceded EnterWorktree. The worktree's committed/inherited allow-rules should apply. Actual: Permissions resolve correctly only when the worktree is established before any main-tree work. Reading main-tree files first anchors the project root (and its permission scope) to the main tree; the subsequent EnterWorktree cwd change does not re-resolve settings against the worktree, so allowed commands prompt again. Likely root cause: Project/local permission settings are resolved once, against the first-established project root, and EnterWorktree changes cwd without re-resolving them against the new worktree. Possibly related: #28041, #31546.

Environment Info

• Platform: darwin
• Terminal: xterm-256color
• Version: 2.1.168
• Feedback ID: 3d8bcb87-7ac1-42a3-b763-fd17e390d4f3

Errors

[]