Claude Code deny rules miss /bin/rm; hook catches it, 10 of 11 blocked

The test grew out of a practical trade-off: to avoid clicking through dozens of confirmation prompts, the developer set Bash commands to run without asking, which removed the human check before a command could touch key files. The repository held two kinds of files that would be painful to lose: .env with keys and passwords, and key files such as .p8 and .pem inside secrets/. An App Store Connect .p8 key, for example, can be downloaded only once, so deleting it means recreating the key and swapping it everywhere it is used.

The deny rules were written as text patterns such as Bash(rm *secrets*) and Read(./secrets/**). They blocked most variants, including cd secrets && rm fake.p8 and timeout 5 rm .env, because the rules look past &&, ; and wrappers like timeout. But /bin/rm does not start with the string rm, and python3 -c hides the delete inside quoted code, so both slipped through. The hook shifts the check from the command text to the destination path, which is why /bin/rm was caught. The same text-matching design also caused over-blocking: rm .env.example and ls secrets were stopped even though they are harmless, and the developer chose to accept that and run those commands manually.

Even combined, the two layers left python3 -c unblocked, and the developer lists further gaps in the 111-line hook, such as sudo -u root rm .env, find . -name '*.p8' -delete, piping .env into curl, and the uppercase rm .ENV. The recommended next step is sandboxing, which restricts which files a command can touch at the operating-system level, so a script that deletes a key would be stopped there rather than by pattern matching.