Tool rejection does not prevent command execution

Bug Report

Description

When a Bash tool call is rejected by the user at the permission prompt, the command still executes before the rejection takes effect. This means destructive commands run even when the user explicitly denies them.

Steps to Reproduce

1. Configure Bash(git:*) in the ask permission list in ~/.claude/settings.json:

``json
"permissions": {
"ask": ["Bash(git:*)"]
}
``

1. Ask Claude to run a compound command starting with git, e.g.:

``bash
git stash --include-untracked && ./scripts/test.sh ... ; git stash pop
``

1. When the permission prompt appears, reject the tool call.

Expected Behavior

The command should not execute at all. The rejection should prevent any side effects.

Actual Behavior

The command executes (fully or partially) before the rejection is processed. In this case, git stash --include-untracked ran and reverted uncommitted changes in the working tree. The git stash pop at the end also ran, but the damage was that files were modified out from under the conversation context — Claude saw the files as reverted and the user had to manually re-apply the stash.

Impact

This defeats the purpose of the ask permission level for destructive operations. Users configure Bash(git:*) as ask specifically to prevent unauthorized git operations, but the permission check happens too late to actually prevent execution.

Environment

• Claude Code CLI
• macOS (Darwin 24.6.0)
• Model: Claude Opus 4.6