[BUG] Bash permission blocking system not enforcing configured restrictions

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

What's wrong?

Claude Code's bash permission blocking system is not enforcing configured restrictions. Commands explicitly listed in the permissions.bash.blocked configuration (including git add, git commit, git push, git reset) execute successfully without any error, warning, or permission prompt, despite being globally blocked with only a specific path exception.

Verification: Bug independently reproduced by Claude Code agent on same system.

What Should Happen?

What should happen?

Commands listed in permissions.bash.blocked should be prevented from executing in all directories EXCEPT those listed in permissions.bash.allowedInPaths. When a blocked command is attempted, it should display an error message such as:

• "Permission denied: 'git add' is blocked by your Claude Code settings"
• "This command requires approval due to security settings"

Error Messages/Logs

### Error messages / logs

**No errors or warnings are produced.** This is part of the problem - blocked commands execute silently with no indication that permission checking was attempted.

**Debug log analysis:**
- Tool-level permissions are loaded correctly
- NO log entries for "blocked", "git add", or "git commit" when these commands execute
- NO evidence of bash command permission checks in debug logs

Steps to Reproduce

Steps to reproduce

Configuration: ~/.config/claude/settings.json

{
  "permissions": {
    "bash": {
      "blocked": [
        "git add*",
        "git commit*",
        "git push*",
        "git reset*"
      ],
      "allowedInPaths": {
        "/home/user/git/personal-repo/**": [
          "git add*",
          "git commit*"
        ]
      }
    }
  }
}

Reproduction steps:

1. Configure bash blocks in settings.json (shown above)
2. Start Claude Code in /home/user/git
3. Navigate to /home/user/git/work-repo (NOT in allowedInPaths)
4. Execute blocked command via Bash tool: git add file.txt
5. Observe: Command executes successfully
6. Verify: git status shows file is staged

Expected: Command should be blocked (work-repo ≠ personal-repo)
Actual: Command executed with no error or permission prompt

Additional complication: Claude Code frequently uses git -C /full/path patterns which would require parsing the -C argument to determine effective working directory for permission checking.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.38

Platform

AWS Bedrock

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Additional context

Security Impact - HIGH:
Users configuring these blocks expect protection against destructive operations. The configuration exists and appears valid, but provides no actual enforcement. This creates a false sense of security.

Configuration file analysis:

• ~/.config/claude/settings.json - Contains bash blocks (active)
• ~/.config/claude-code/settings.json - Empty {}
• ~/.claude.json - Cache/state only, no permissions
• Project .claude.json - Does not exist

Result: No conflicting settings. Configuration is unambiguous.

Evidence of community impact:

• Multiple users have noticed issues with git command patterns
• One user added workaround to CLAUDE.md: "Git: Do not use git -C <path> when already in the correct working directory"
• Suggests broader awareness that git command handling is problematic

Test results:

| Command | Expected | Actual | Pass? |
|---------|----------|--------|-------|
| git add <file> | BLOCKED | Succeeded | ❌ |
| git commit -m "..." | BLOCKED | Succeeded | ❌ |
| git reset HEAD~1 | BLOCKED | Succeeded | ❌ |
| git status | Allowed | Succeeded | ✅ |
| git diff | Allowed | Succeeded | ✅ |

Pattern: Allowed commands work correctly, but blocked commands are not being blocked.