Document deny/allow rule precedence in settings.json permissions

Summary

When a file path matches both a deny and an allow pattern in settings.json permissions, the behavior is undocumented. Which takes precedence?

Use Case

FluxEngine uses a multi-tenant isolation model where each client instance has a settings.json with:

{
  "permissions": {
    "deny": [
      "Read(C:\Users\cmoor\OneDrive*\2 - BUSINESS\**)"
    ],
    "allow": [
      "Read(C:\Users\cmoor\OneDrive - turnkeytel.com\2 - BUSINESS\2.5 - MSI Mechanical Services Ltd\**)"
    ]
  }
}

The deny rule blocks the entire business directory. The allow rule permits one specific client subdirectory. This pattern works as a "deny all, allow specific" approach — but only if deny is evaluated first and allow acts as an override (or vice versa with clear documentation).

What's Unclear

1. Evaluation order: Is it deny-first-then-allow, allow-first-then-deny, or most-specific-wins?
2. Wildcard specificity: Does OneDrive* in deny match differently than the literal OneDrive - turnkeytel.com in allow?
3. Edge case: What if the path matches deny but not allow (e.g., C:\...\2 - BUSINESS\ without the specific client suffix)?

Request

Please document the deny/allow precedence behavior in the Claude Code permissions documentation, specifically:

• Which takes precedence when both match
• Whether specificity matters (more specific path wins)
• Recommended patterns for "deny all, allow specific" use cases

Environment

• Claude Code CLI
• Windows 11
• settings.json in .claude/settings.json per project