Allow list exact match should take precedence over deny list wildcard pattern

Bug Description

When a command in the allow list (e.g., Bash(git add runtime)) is first attempted as part of a combined command (with &&), subsequent attempts of the exact allowed command alone are also rejected.

Environment

• Claude Code Version: 2.0.76
• OS: Linux 5.15.167.4-microsoft-standard-WSL2 (Ubuntu on WSL2)
• Shell: Bash

Configuration

In .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(git add runtime)",
      "Bash(git add cmake)"
    ]
  }
}

Steps to Reproduce

1. Configure allow list with Bash(git add runtime)
2. Attempt to run: git add runtime && git diff --cached --name-status

• Result: Permission denied (expected, since combined command doesn't match exactly)

1. Immediately attempt to run: git add runtime

• Result: Permission denied (unexpected, should match allow list exactly)

1. Attempt to run: /usr/bin/git add runtime

• Result: Success (workaround)

Expected Behavior

Step 3 should succeed because git add runtime exactly matches the allow list entry Bash(git add runtime).

Actual Behavior

Step 3 is rejected, even though it's an exact match. Only using the full path /usr/bin/git add runtime works as a workaround.

Possible Causes

1. Permission cache/state issue after a rejection
2. Command prefix matching interfering with exact matching
3. Session state not properly reset between permission checks

Workaround

Use full path: /usr/bin/git add runtime instead of git add runtime

Additional Context

This occurred during a git commit workflow where the submodule reference needed to be staged after pushing the submodule changes.