Allow pre-approving EnterWorktree for worktree paths outside .claude/worktrees/

Open 💬 1 comment Opened Jul 13, 2026 by indianajensen

Feature request

Add a permission rule (or settings option) to pre-approve EnterWorktree for worktree paths outside .claude/worktrees/, e.g. a path-pattern allow rule in settings.json:

{
  "permissions": {
    "allow": [
      "EnterWorktree(/Users/me/github/my-repo-*)"
    ]
  }
}

or, alternatively, a project-level setting declaring additional trusted worktree roots.

Background

Since ~2.1.206/2.1.207, EnterWorktree requests confirmation before entering a worktree outside .claude/worktrees/:

permission-root relocation to "/Users/me/github/my-repo-796-feature-slug" — a model-supplied worktree outside .claude/worktrees/ — Do you want to proceed?

The security rationale is sound as a default: a model-supplied path outside the granted permission root should not silently relocate the session. No objection to the guard itself.

The problem

Many repos manage worktrees with their own tooling, using the conventional git layout of sibling directories (../my-repo-<issue>-<slug>) rather than nesting them inside the main working tree. In our monorepo, a helper script creates the worktree (branch off main, env carry-over, dependency install, issue labelling), and the session then calls EnterWorktree with that path. This happens many times a day, including from background build agents running unattended — each of which now stalls on a permission prompt until a human answers.

There is currently no way to express "worktrees matching this pattern are ours and trusted":

  • No EnterWorktree(...) rule syntax exists in the permissions documentation.
  • The only prompt-free path is relocating all worktrees into .claude/worktrees/, which forces a repo-tooling migration (paths, ignores, tool-recursion guards for a nested full checkout) purely to satisfy the harness convention, when sibling worktrees are the standard git convention.

Ask

  1. Support an allow-rule specifier for EnterWorktree with path patterns, mirroring existing rules like Read(path) / Cd(path), so a user can durably pre-approve their own worktree layout.
  2. Failing that, a settings key (project or user scope) listing additional trusted worktree roots/patterns that EnterWorktree treats like .claude/worktrees/.

Environment

  • Claude Code 2.1.207 (behaviour first observed after auto-update from 2.1.205; 2.1.206 installed 10 Jul, 2.1.207 installed 11 Jul)
  • macOS (darwin 25.5.0)
  • Worktrees created by repo script as siblings of the primary checkout, entered via EnterWorktree in interactive sessions and by background agents

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗