Bug

Bash(git *) in settings.json permissions does not auto-approve multiline bash commands that start with git, such as compound commands with &&, backslash line continuations, or heredoc $(cat <<'EOF' ...) patterns.

Steps to Reproduce

1. Add "Bash(git *)" to ~/.claude/settings.json permissions allow list
2. Have Claude Code generate a command like:

git add file1.md file2.md && \
git commit -m "$(cat <<'EOF'
commit message here
EOF
)"

3. Claude Code prompts for permission despite the command starting with git

Expected Behavior

Bash(git *) should match any bash command whose text starts with git , regardless of whether the command contains newlines, heredocs, backslash continuations, or && chains.

Actual Behavior

The permission prompt appears every time. Clicking "Yes, and don't ask again" appends the entire verbatim multiline command (including full heredoc content) as a new allow rule in .claude/settings.local.json. These verbatim rules:

• Never match a second time (commit messages are unique)
• Pollute settings.local.json with hundreds of lines of junk
• Create a feedback loop where the file grows unboundedly

Impact

This effectively makes it impossible to auto-approve any non-trivial bash command through the permission system. Users are forced to either:

• Click "Yes" on every single compound command (dozens per session)
• Use --dangerously-skip-permissions to bypass the entire system

The permission system is generating commands that it cannot authorize, which defeats its purpose.

Environment

• Claude Code CLI (latest as of 2026-02-13)
• Linux (Ubuntu 22.04)
• Settings in both ~/.claude/settings.json and .claude/settings.local.json

Suggested Fix

The * wildcard in Bash() permission rules should match against the full command text including newlines, not just the first line. Alternatively, provide a way to allow all invocations of a tool (e.g., Bash with no parentheses to allow all bash commands).