[BUG] Bash(ls:*) allow rule still prompts for ls commands in settings.local.json

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/29529
2. https://github.com/anthropics/claude-code/issues/30071
3. https://github.com/anthropics/claude-code/issues/30113

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Facing similar here for Next.js projects, closed my own issue https://github.com/anthropics/claude-code/issues/33827 so this can get consolidated.

Same issue. It's a real pain, and it's not just ls but basically all Bash commands from what I can tell. grep, tail, etc. None of my allow configuration seems to be respected anymore.

Experiencing on MacOS Tahoe 26.3.1 with Claude Code 2.1.75.

Almost positive it's when a bash command has unescaped () characters in it's arguments.

Quick script to reproduce with ls:

#!/bin/bash

# Setup
echo "Setting up two directories, one with parentheses and one without..."
mkdir claude-permissions-test
mkdir "claude-permissions-test/1-path-with-(parens)"
touch "claude-permissions-test/1-path-with-(parens)/sample.txt"
mkdir claude-permissions-test/2-path-without-parens

echo ""
echo "Directories created in ./claude-permissions-test/:"
ls -l claude-permissions-test

# Run both in parallel, capture output
echo ""
echo "Running two inline Claude prompts in parallel to ls each subdir..."
cd claude-permissions-test
claude -p "Run \`ls '1-path-with-(parens)'\`" --allowedTools "Bash(ls *)" --output-format text > parens-result.txt 2>&1 &
claude -p "Run \`ls '2-path-without-parens'\`" --allowedTools "Bash(ls *)" --output-format text > no-parens-result.txt 2>&1 &
wait

# Result
echo ""
echo "Path with parens result:"
cat parens-result.txt

echo ""
echo "Path without parens result:"
cat no-parens-result.txt

Result:

Setting up two directories, one with parentheses and one without...

Directories created in ./claude-permissions-test/:
total 16
drwxr-xr-x@ 3 rdavidson  staff   96 Mar 16 10:37 1-path-with-(parens)
drwxr-xr-x@ 2 rdavidson  staff   64 Mar 16 10:37 2-path-without-parens
-rw-r--r--@ 1 rdavidson  staff   48 Mar 16 10:37 no-parens-result.txt
-rw-r--r--@ 1 rdavidson  staff  135 Mar 16 10:37 parens-result.txt

Running two inline Claude prompts in parallel to ls each subdir...

Path with parens result:
The command requires approval. Please approve the `ls '1-path-with-(parens)'` command to proceed.

Path without parens result:
The directory `2-path-without-parens` exists but is empty.

Same issue here for a next.js project with (route-groups) in file paths 👍

Same issue here. My project lives on a Google Drive path with spaces, and I have "Bash" (bare, matches all) in allow with specific patterns like "Bash(git push *)" in both ask and deny — neither takes precedence over the broad "Bash" allow.

Tested on macOS Tahoe, Claude Code in VS Code, Opus model:

• "Bash" in allow + "Bash(git push *)" in ask → push runs without prompting
• "Bash" in allow + "Bash(git push *)" in deny → push still runs without prompting
• "Bash(git diff *)" in allow (no bare "Bash") → git diff --stat HEAD~1 still prompts

So the pattern matching is broken in both directions: specific rules can't override a broad allow, and specific allow rules don't match multi-arg commands.

Update/workaround: We worked around this by removing bare "Bash" from allow entirely and using a PreToolUse hook for granular bash command permissions. The hook inspects the command string and returns allow, ask, or deny dynamically.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "/path/to/bash-permissions.sh"
          }
        ]
      }
    ]
  }
}

The hook script splits compound commands (&&, ;, |), checks each subcommand against allow/ask/deny patterns using grep -qE with [[:space:]] (not \s — macOS grep -E doesn't support it), and returns the appropriate permissionDecision. This gives full control that the permissions system currently can't provide.

Note: if your project path contains spaces (e.g. Google Drive), $CLAUDE_PROJECT_DIR in the hook command path won't work — use a quoted absolute path instead.

@sapient-christopher good job! Could you provide your bash-permissions.sh script?

@nikicat see attached.
bash-permissions.sh

@sapient-christopher thanks!

/tmp/gh-comment-body.txt

Worth pointing out that this still happens _even when the parens are in a single-quoted string_