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

Status Open
Reported on v2.1.206
Maintainer reply None cached
Activity 5 comments · opened Jul 13, 2026

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 ↗

3 Comments

damusix · 1 month ago

Yeah forcing it on .claude/worktrees vs a settings.json config is silly. Also, forcing a worktree-* prefix is also silly. Let the agent call the branch whatever, eg: git worktree add -b fix/some-bug PE-145-fix-some-bug. Why not make the tool EnterWorktree('...path...', '...branch...') so claude can adapt to our work standards?

jackwh · 1 month ago

This definitely needs fixing. Claude Code's default nested worktrees are a nonsensical anti-pattern to begin with, now Claude's blocked on human approval simply for entering a project's known sibling worktree folder? Make it make sense! I hope they fix this soon.

rvanvelzen · 11 days ago

This definitely needs fixing - the only way around this is to use "bypass permissions" which is... Not advisable.

Showing cached comments. Read the full discussion on GitHub ↗