Feature: directory-scoped permission allow rules

Feature Request

Problem

The permissions.allow rules in settings.json operate at the tool level with no directory scoping. For example, Bash(*) auto-approves all shell commands regardless of what directory they target. This creates an all-or-nothing tradeoff:

• Allow globally: Convenient but risky — a misunderstood instruction could be destructive to files outside the project.
• Prompt for everything: Safe but noisy — users get frequent permission prompts for routine operations within their project workspace.

Users who want to grant Claude broad autonomy within the launch directory while retaining approval prompts for operations outside it have no way to express this today.

Proposed Solution

Add directory-scoped variants of permission allow rules that restrict auto-approval to the launch directory (and any paths listed in permissions.additionalDirectories). For example:

{
  "permissions": {
    "allow": [
      "Bash(*):scoped",
      "Edit:scoped",
      "Write:scoped"
    ]
  }
}

Where :scoped (or a similar modifier) means the rule only auto-approves when the tool's target path falls within the project/launch directory. Operations targeting paths outside that scope would still trigger a permission prompt.

Context

• The schema already has permissions.additionalDirectories for expanding the permission scope, suggesting directory-based boundaries are already part of the model.
• This would be especially valuable in ~/.claude/settings.json (global settings), where users want a sensible default across all projects without granting unrestricted system-wide access.
• The CLAUDE.md behavioral instructions can guide the agent to stay within scope, but that's a soft guardrail — a hard permission boundary would be much more trustworthy.

Alternatives Considered

• Per-project .claude/settings.json: Works but requires duplicating config in every project, and still doesn't actually enforce directory boundaries on Bash(*).
• Relying on CLAUDE.md instructions: Behavioral guidance is helpful but not a security boundary.
• Using restrictive permission modes: Modes like default prompt too aggressively for power users; bypassPermissions is too permissive.

🤖 Generated with Claude Code