guard-bash.sh refuses some commands outright that settings.json's permission tiers only mark ask.
This is deliberate — the hook can see into compound Bash commands that a path/prefix permission rule cannot — but it means the approval prompt you'd expect from the ask tier never appears.
You get a flat refusal instead.
| Command | settings.json says |
guard-bash.sh does |
|---|---|---|
git rebase |
ask | blocks |
doctrine-migrations migrate / execute |
ask | blocks |
fixtures:execute, schema:drop, schema:update (via bin/cli.php) |
ask | blocks |
composer development-enable / -disable |
— | blocks |
pip install, git checkout --, git filter-branch |
— | blocks |
Everything else under ask — commits, mysql, the config and QA files — prompts as documented in Permissions Reference.
Editing settings.local.json will not reach a hook-level block — that override layer only affects the permission tiers.
To allow one of these commands, edit guard-bash.sh itself, and do so deliberately: every command in this table is either a schema-mutating or history-rewriting operation, which is why it's blocked at the hook layer instead of left to a prompt someone could approve on autopilot.