Allow pre-approving EnterWorktree for worktree paths outside .claude/worktrees/
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
- Support an allow-rule specifier for
EnterWorktreewith path patterns, mirroring existing rules likeRead(path)/Cd(path), so a user can durably pre-approve their own worktree layout. - Failing that, a settings key (project or user scope) listing additional trusted worktree roots/patterns that
EnterWorktreetreats 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
EnterWorktreein interactive sessions and by background agents
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Yeah forcing it on
.claude/worktreesvs a settings.json config is silly. Also, forcing aworktree-*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 toolEnterWorktree('...path...', '...branch...')so claude can adapt to our work standards?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.
This definitely needs fixing - the only way around this is to use "bypass permissions" which is... Not advisable.