[FEATURE] Trusted workspace patterns to skip trust prompt for git worktrees

Upvoting, this would be a great feature.

though minor, this is a very real point of friction for any serious worktree-heavy workflows. big +1!

Workaround: Parent directory trust cascading

The trust state is stored in ~/.claude.json under the projects key per directory path. Crucially, Claude Code walks parent directories when checking trust — so if a parent is trusted, all subdirectories inherit that trust.

One-liner fix — add your home directory (or any common root) as trusted:

python3 -c "
import json
with open('$HOME/.claude.json', 'r+') as f:
    d = json.load(f)
    d.setdefault('projects', {}).setdefault('$HOME', {})['hasTrustDialogAccepted'] = True
    f.seek(0); json.dump(d, f, indent=2); f.truncate()
"

This works for the home directory bug (#18942), git worktrees, and any new directory you open — no prompt ever again.

Found by reverse-engineering the compiled binary: the check function (checkHasTrustDialogAccepted) iterates up the directory tree via while(!0) { if(T.projects?.[_]?.hasTrustDialogAccepted) return true; ... }.

That said, a proper trustedWorkspacePatterns setting as proposed in this issue would be the clean solution — the workaround above is a blunt "trust everything" approach.

Upvote, as this would make it possible to do bash -c 'claude --new-flag /usage'. Or rather it would be cool if it was exposed such.

+1 — I frequently launch Claude Code from my home directory and get this prompt every single session, even with bypassPermissions already set in settings.json. A trustedDirectories setting (or respecting the existing permission mode as implicit trust) would be a great quality-of-life improvement.

+1 on this. My use case is slightly different from worktrees but the core problem is the same.

I run Claude Code from my home directory (~) because I frequently need to edit dotfiles and system-level config files. Every single session, I get the trust prompt, and selecting "Yes, I trust this folder" does not persist — it asks again on the next launch.

Environment:

• macOS (Darwin 25.2.0, Apple Silicon)
• Claude Code v2.1.76
• Shell: fish
• ~/.claude/settings.json has bypassPermissions mode enabled

Observed behavior:

• No trust-related key is written to ~/.claude.json after confirming trust
• No trustedDirectories file is created anywhere under ~/.claude/
• The prompt reappears on every new session in the same directory

A trustedWorkspacePatterns setting (or even a simple trustedDirectories list) would solve this for both worktree users and home-directory users alike.

A PreToolUse hook can implement trusted workspace patterns:

TRUSTED='($HOME/projects|$HOME/work|$HOME/repos|/workspace)'
CWD=$(pwd)
if echo "$CWD" | grep -qE "$TRUSTED"; then
    echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"allow","permissionDecisionReason":"Trusted workspace"}}'
fi
exit 0

Store patterns in a config file:

// ~/.claude/trusted-workspaces.json
{"patterns": ["/home/user/projects/*", "/workspace/*"]}

Read dynamically:

for p in $(jq -r '.patterns[]' ~/.claude/trusted-workspaces.json 2>/dev/null); do
    [[ "$CWD" == $p ]] && echo '{"hookSpecificOutput":{..."allow"...}}' && exit 0
done

A PreToolUse hook can implement trusted workspace patterns: TRUSTED='($HOME/projects|$HOME/work|$HOME/repos|/workspace)' CWD=$(pwd) if echo "$CWD" | grep -qE "$TRUSTED"; then echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"allow","permissionDecisionReason":"Trusted workspace"}}' fi exit 0 Store patterns in a config file: // ~/.claude/trusted-workspaces.json {"patterns": ["/home/user/projects/", "/workspace/"]} Read dynamically: for p in $(jq -r '.patterns[]' ~/.claude/trusted-workspaces.json 2>/dev/null); do [[ "$CWD" == $p ]] && echo '{"hookSpecificOutput":{..."allow"...}}' && exit 0 done

No, this won't work. The workspace trust dialog happens before the session starts — it's a pre-session prompt, not a tool call. PreToolUse hooks only fire once you're already inside a session and Claude is about to use a tool.

The trust dialog is at a different layer entirely:

1. Workspace trust dialog → fires on launch, before any hooks or tools exist
2. PreToolUse hooks → fire during a session when Claude invokes a tool

So the hook would never get a chance to intercept the trust prompt. It's like trying to use an in-app setting to bypass the app's login screen.

~/.claude.json

{
  "projects": {
    "/workspace": {
      "hasTrustDialogAccepted": true
    }
  }
}

It works for subdirectories.

Update: This is the same as what was said above, only more straightforward.

+1 on this, and one extension worth considering: the same "trusted workspace" decision should also suppress bash safety heuristics inside that workspace — not just the launch dialog.

Concretely, today's escape valves are all-or-nothing:

• bypassPermissions — kills every prompt including ones I actually want (npm install, rm -rf, MCP tool calls)
• Per-pattern allowlists — verbose, repo-leaky, and don't help against heuristic prompts like the cd <path> && git ... "untrusted hooks" warning (#30435), which fires regardless of what's in permissions.allow

If trust were a real scope rather than a one-shot dialog dismissal, the harness could:

1. Skip the launch prompt (this issue's ask)
2. Auto-allow standard git read + mutation subcommands inside the repo
3. Suppress heuristic prompts like cd && git when both the source and target paths are trusted repos — which is exactly the worktree → main-repo merge flow

Path-glob trust (~/git/my-org/*) works, but remote URL as the trust key is more robust — worktrees inherit the same remote, so trust follows the code rather than the directory. Something like:

{
  "trustedRepos": [
    { "remote": "git@github.com:my-org/*" },
    { "path": "~/git/personal/*" }
  ]
}

Prior art: VS Code Workspace Trust, git's safe.directory. Both treat trust as a scoped, repo-level concept — which is what's missing here.

2.1.232 made this considerably more painful: the changelog entry "Fixed nested git repositories inheriting trust from a parent directory; each repository now requires its own trust confirmation" removed the one thing that was making worktree-heavy workflows bearable — a worktree under an already-trusted parent used to just work. Understood as a deliberate security fix, but it landed with no accompanying mitigation (no path pattern, no additionalDirectories-equivalent for trust, nothing), so now every git worktree add under a trusted repo re-triggers the full trust dialog with zero workaround. Given this issue has been open and asking for exactly that mitigation, it'd be good to see the trust-pattern feature ship alongside — or before — security tightenings like this one that remove existing (if imperfect) affordances.