Path-scoped permission rules: allow paths should override catch-all ask

Feature Request

Problem

There's no working way to create a "dev sandbox" — a directory tree where Read/Edit/Write are auto-allowed, while still prompting for those same tools outside that directory.

The expected configuration would be:

{
  "permissions": {
    "allow": [
      "Read(/home/user/dev/**)",
      "Edit(/home/user/dev/**)",
      "Write(/home/user/dev/**)"
    ],
    "ask": [
      "Read",
      "Edit",
      "Write"
    ]
  }
}

Expected behavior: Reads/edits/writes inside /home/user/dev/ are auto-allowed. Outside that path, the user is prompted.

Actual behavior: The catch-all ask rule for Read/Edit/Write always wins. The path-scoped allow rules are ignored. Every read/edit/write prompts regardless of location.

What I've tried

• Single slash absolute paths: Read(/home/user/dev/**)
• Double slash absolute paths: Read(//home/user/dev/**)
• Tilde home paths: Read(~/dev/**)
• Project-level .claude/settings.json with allow rules (user-level ask overrides them)

None of these override the catch-all ask for the same tool.

Use case: Dev sandbox

Many developers keep all their projects under a single directory (e.g. ~/dev/, ~/projects/, ~/code/). The ideal workflow:

1. Inside the dev directory — Claude operates freely. Read, edit, write, no prompts. This is your workspace, you trust it.
2. Outside the dev directory — Claude asks before reading or modifying anything. System files, config, home directory docs, etc. should require explicit approval.
3. Destructive operations — Always ask regardless of location (e.g. rm, git push --force).

This "sandbox" pattern is a natural security boundary. You get full productivity inside your workspace and protection everywhere else.

Proposed behavior

When a path-scoped allow rule and a catch-all ask rule exist for the same tool, the path-scoped rule should take priority for matching paths:

allow: Read(/home/user/dev/**) + ask: Read
  → Read inside /home/user/dev/ = auto-allowed
  → Read outside /home/user/dev/ = prompted

The more specific rule should win over the less specific rule, regardless of which list it appears in.

Current workaround

Remove Read/Edit/Write from all permission lists entirely, then manually approve "allow for this session" at the start of each session. This works but:

• Loses the path-scoping entirely (session allow is global)
• Requires manual approval every new session
• Defeats the purpose of persistent permission configuration

Environment

• macOS
• Claude Code CLI