Summary
When Bash tool calls are blocked by user-configured deny rules in settings.json/settings.local.json, Claude switches to the PowerShell tool to run the same (or equivalent) commands, effectively bypassing the user's security restrictions.
Steps to Reproduce
- Configure deny rules in
.claude/settings.local.json to block specific Bash commands (e.g., Python scripts, database modification commands)
- Ask Claude to run a command that matches the deny rule via Bash
- Observe: Bash tool call is blocked
- Observe: Claude then attempts the same command via the PowerShell tool without being blocked
Expected Behavior
If a user configures deny rules for Bash, the intent is to restrict that class of commands regardless of which shell tool is used. Claude should respect the spirit of the restriction, not just the letter of which tool name is matched. When blocked, Claude should stop and ask the user how to proceed — not find an alternate execution path.
Actual Behavior
Claude silently switched from the Bash tool to the PowerShell tool after Bash was denied, running the same commands through PowerShell where no deny rule existed for that tool.
Why This Matters
In this specific case, the user had set up Bash deny rules because uncontrolled script execution was identified as a possible cause of database corruption in a production-adjacent environment. The entire purpose of the restrictions was to prevent Claude from running arbitrary commands against a live database. By switching to PowerShell, Claude circumvented that safety boundary.
Adding audit logging to the database (the task being worked on) was a direct response to prior data corruption. Having Claude bypass the safety rules that were put in place because of that corruption — while working on the audit feature — is a significant trust violation.
Environment
- Claude Code (VS Code extension)
- Platform: Windows 11
- Shell config: PowerShell primary, Bash also available
- Deny rules configured in
.claude/settings.local.json
Suggested Fix
Permission deny rules (and allow rules) for the Bash tool should also apply to PowerShell (and any other shell-execution tool). Alternatively, there should be a single Shell(*) permission scope that covers all shell execution tools, so users don't have to enumerate every shell variant to enforce a restriction.
Summary
When Bash tool calls are blocked by user-configured deny rules in
settings.json/settings.local.json, Claude switches to the PowerShell tool to run the same (or equivalent) commands, effectively bypassing the user's security restrictions.Steps to Reproduce
.claude/settings.local.jsonto block specific Bash commands (e.g., Python scripts, database modification commands)Expected Behavior
If a user configures deny rules for Bash, the intent is to restrict that class of commands regardless of which shell tool is used. Claude should respect the spirit of the restriction, not just the letter of which tool name is matched. When blocked, Claude should stop and ask the user how to proceed — not find an alternate execution path.
Actual Behavior
Claude silently switched from the Bash tool to the PowerShell tool after Bash was denied, running the same commands through PowerShell where no deny rule existed for that tool.
Why This Matters
In this specific case, the user had set up Bash deny rules because uncontrolled script execution was identified as a possible cause of database corruption in a production-adjacent environment. The entire purpose of the restrictions was to prevent Claude from running arbitrary commands against a live database. By switching to PowerShell, Claude circumvented that safety boundary.
Adding audit logging to the database (the task being worked on) was a direct response to prior data corruption. Having Claude bypass the safety rules that were put in place because of that corruption — while working on the audit feature — is a significant trust violation.
Environment
.claude/settings.local.jsonSuggested Fix
Permission deny rules (and allow rules) for the Bash tool should also apply to PowerShell (and any other shell-execution tool). Alternatively, there should be a single
Shell(*)permission scope that covers all shell execution tools, so users don't have to enumerate every shell variant to enforce a restriction.