[FEATURE] Regex/glob support for Bash permission patterns

Another use-case I've run into is that I want to allow all get/list/describe commands for any AWS service via the AWS CLI.

However, the current allow behavior does not let me define something simple like:

Bash(regex:^aws\s+\S+\s+(get|list|describe)-.*$)

I would have to list out the hundreds of options to accomplish this now.

Another use case: git subcommands with optional flags.

I want a single pattern that allows both:

• git grep pattern
• git -C /path/to/repo grep pattern

Current options and their problems:

1. Two patterns (works but duplicative):

``json
"Bash(git grep:*)",
"Bash(git -C * grep:*)"
``

1. Single permissive pattern Bash(git * grep:*) — but this matches dangerous commands where "grep" appears as a branch/ref name:

• git push --force origin grep
• git reset --hard grep
• git branch -D grep

With regex support, this could be expressed safely:

"Bash(regex:^git\\s+(-C\\s+\\S+\\s+)?grep\\s)"

This pattern makes -C <path> optional while ensuring grep is the actual subcommand, not a ref name.

Use case: Real-world workflow automation with trust boundaries

I'm building automated workflows with Claude Code on a React Native project (TiedSiren51) and I need fine-grained permissions because I can't blindly trust the agent.

My current settings.local.json has 200+ allow rules, 104 deny rules, and 30 ask rules — and it's still not airtight. Here's a condensed excerpt showing the problem:

Problem 1: Blocking hook bypasses requires N rules per git subcommand

"deny": [
  "Bash(git commit --no-verify:*)",
  "Bash(git push --no-verify:*)",
  "Bash(git merge --no-verify:*)",
  "Bash(git rebase --no-verify:*)",
  "Bash(git cherry-pick --no-verify:*)",
  "Bash(git revert --no-verify:*)",
  "Bash(git am --no-verify:*)"
]

With regex, this collapses to one rule:

"Bash(regex:^git\\s+\\S+\\s+.*--no-verify)"

Problem 2: Env var prefix evasion requires combinatorial explosion

I have a pre-push hook that checks E2E status. Claude sometimes tries to skip it. I need to block every combination:

"deny": [
  "Bash(SKIP_E2E_CHECK=true git push --force:*)",
  "Bash(SKIP_E2E_CHECK=true git push --force-with-lease:*)",
  "Bash(SKIP_E2E_CHECK=true git push -f:*)",
  "Bash(SKIP_E2E_CHECK=true git push origin main:*)",
  "Bash(SKIP_E2E_CHECK=1 git push --force:*)",
  "Bash(SKIP_E2E_CHECK=1 git push -f:*)",
  "// ... 16 rules total for this one concern"
]

With regex:

"Bash(regex:^SKIP_E2E_CHECK=\\S+\\s+git\\s+push\\s+(-f|--force|--force-with-lease|origin\\s+(main|master)))"

Problem 3: Allow rules can't express "subcommand families"

I allow all read-only gh operations but must list each one individually (20+ rules). With regex:

"Bash(regex:^gh\\s+(issue|pr|run|repo|project)\\s+(view|list|status|checks|diff))"

The full file (378 lines) is visible in my project at .claude/settings.local.json. It works, but maintaining it is painful and the combinatorial gaps make it unreliable as a real security boundary.

Regex support would make permissions both more expressive and more maintainable for users who are seriously investing in Claude Code workflows.

Use case: cd <path> && <safe-command> patterns

I analyzed my recent sessions and found that 32% of all Bash commands required manual approval (266 out of 820). The #1 cause: commands prefixed with cd "/path/to/project" && ....

Claude Code frequently generates commands like:

cd "/Users/me/Projects/my-project" && python3 script.py
cd "/Users/me/Projects/my-project" && source venv/bin/activate
cd "/Users/me/Projects/my-project/subdir" && grep -r "pattern" .

I already have Bash(python3:*), Bash(source:*), Bash(grep:*) in my allow list — but these don't match when the command starts with cd.

The core problem: the path after cd varies (different subdirectories, different projects), so there's no fixed prefix that captures "cd to any directory, then run a safe command."

• Bash(cd:*) is too broad — it would auto-approve cd /dir && rm -rf *
• Enumerating every cd "/specific/path" && python3:* combination is impractical
• There's no way to express "cd <wildcard> && python3" with prefix-only matching

This single gap accounts for ~170 manual approvals per session cycle (~64% of all friction).

With regex/glob support, this could be:

"Bash(regex:^cd\\s+\"[^\"]+\"\\s+&&\\s+(python3?|source|grep|ls|cat|echo|node)\\s)"

Or even more elegantly, a way to compose existing allow rules so they match regardless of cd prefix.

A PreToolUse hook can implement full regex matching today:

CMD=$(cat | jq -r '.tool_input.command // empty' 2>/dev/null)
[ -z "$CMD" ] && exit 0
DENY_PATTERNS=(
    'find.*-exec'
    'git\s+push\s+--force'
    'git\s+reset\s+--hard'
    'rm\s+-rf\s+[/~]'
    'curl.*-X\s+(POST|PUT|DELETE)'
    'ssh.*rm\s'
    'chmod\s+777'
)
for pattern in "${DENY_PATTERNS[@]}"; do
    if echo "$CMD" | grep -qE "$pattern"; then
        echo "BLOCKED: Command matches deny pattern: $pattern" >&2
        exit 2
    fi
done
ALLOW_PATTERNS=(
    '^git\s+(status|log|diff|show|branch|blame|tag)\b'
    '^(cat|head|tail|less|wc|file|stat|ls|tree)\s'
    '^(grep|rg|ag)\s'
    '^find\s+.*-name\s'         # find without -exec is safe
    '^(npm|yarn)\s+(test|run|list|info|outdated)\b'
    '^python3?\s+-m\s+pytest\b'
    '.*--help$'                 # any command ending in --help
    '.*--version$'
    '.*--dry-run\b'
)
for pattern in "${ALLOW_PATTERNS[@]}"; do
    if echo "$CMD" | grep -qE "$pattern"; then
        echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"allow","permissionDecisionReason":"Matches allow regex"}}'
        exit 0
    fi
done
exit 0

Add to ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{ "type": "command", "command": "bash ~/.claude/hooks/bash-regex-permission.sh" }]
    }]
  }
}

This gives you:

• Deny rules: find.*-exec blocked, find -name allowed
• Allow rules: --help, --version, --dry-run auto-approved regardless of the base command
• Argument-aware matching: git push blocked but git push --dry-run allowed
• Full regex: anything grep -E supports

You can also load patterns from a config file for easy customization:

while IFS= read -r pattern; do
    [[ "$pattern" =~ ^#|^$ ]] && continue
    if echo "$CMD" | grep -qE "$pattern"; then
        echo "BLOCKED: $pattern" >&2; exit 2
    fi
done < ~/.claude/bash-rules-deny.conf

Hooks give you full regex support for permission matching — no need to wait for native glob/regex in settings.json:

INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty' 2>/dev/null)
[ -z "$COMMAND" ] && exit 0
ALLOW_PATTERNS=(
    '^git\s+(status|log|diff|show|branch|tag|remote|ls-files|blame|rev-parse)'
    '^(ls|cat|head|tail|wc|stat|file|du|find|tree|which)\s'
    '^(grep|rg|ag|awk|sed|sort|uniq|cut|tr|jq|yq)\s'
    '^npm\s+(test|run|ls|info|view|audit)'
    '^python3?\s+(-c|-m\s+(json|pytest|py_compile))'
    '^(echo|printf|true|false|test|env|date|sleep|pwd)\s'
    '^mkdir\s'
    '^curl\s+(-s\s+)?https?://'  # GET-only curl
)
for pattern in "${ALLOW_PATTERNS[@]}"; do
    if echo "$COMMAND" | grep -qE "$pattern"; then
        jq -n '{hookSpecificOutput:{hookEventName:"PreToolUse",permissionDecision:"allow",permissionDecisionReason:"Regex pattern match: '"$pattern"'"}}'
        exit 0
    fi
done
exit 0

INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty' 2>/dev/null)
[ -z "$COMMAND" ] && exit 0
DENY_PATTERNS=(
    'rm\s+-[a-z]*r[a-z]*f'
    'git\s+(reset\s+--hard|clean\s+-f|push\s+.*--force)'
    'DROP\s+(TABLE|DATABASE)'
    'curl.*\|\s*(ba)?sh'
)
for pattern in "${DENY_PATTERNS[@]}"; do
    if echo "$COMMAND" | grep -qiE "$pattern"; then
        echo "BLOCKED by deny pattern: $pattern" >&2
        exit 2
    fi
done
exit 0

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [
        { "type": "command", "command": "bash ~/.claude/hooks/regex-deny.sh" },
        { "type": "command", "command": "bash ~/.claude/hooks/regex-permissions.sh" }
      ]
    }]
  }
}

Full regex support with no limitations — grep -qE gives you extended regex. You can match command arguments, flags, paths, pipe chains — anything the built-in glob/pattern system can't handle.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Adding a concrete failure mode I ran into, since it's a sharper version of the same root cause (glob-only Bash matching) and I think it strengthens the case for reopening this.

Bracket expressions ([0-9]) silently fail closed — no error, rule just never matches.

I wrote allow rules intended to match any 4-digit port:

Bash(curl http://localhost:8[0-9][0-9][0-9]/*)

This looks reasonable because Read/Edit permission rules do support gitignore-style bracket expressions. But Bash rules only support a single * wildcard — there's no bracket-expression spec for them. So [0-9] isn't parsed as "any digit," it's matched as five literal characters: [, 0, -, 9, ]. The rule compiles fine, saves fine, and then simply never matches any real command. There's no warning, no lint, nothing in the UI or logs to indicate the rule is dead on arrival — you only find out when Claude hits an unexpected permission prompt for a command you thought you'd already allowed (or, worse, you don't notice and just assume it's working).

Given Read/Edit already implement bracket-expression matching, exposing the same capability for Bash rules seems like a small, well-scoped slice of this larger regex/glob ask — and one that would also close the "silent failure" gap, since a real character-class engine would make [0-9] behave as users already expect from every other tool that uses gitignore-style globs.

Given this is a live, concrete case (not hypothetical) and the two other duplicate threads (#37509, #25495) also just went stale rather than being rejected on the merits, would it be possible to reopen this?