Claude Code’s deny rules look at the command as a whole, but they match against individual patterns. When a command chains cd with a destructive operation, the cd is what gets evaluated first. The dangerous part slips through.

Two issues filed this week demonstrate the same gap:

#37621 shows that cd .. && testcommand abc bypasses a deny rule on testcommand. The deny rule fires when testcommand abc runs alone, but not when it follows cd .. in a compound statement.

#37662 provides a thorough analysis with a table showing that rm -rf passes through when chained with &&, ;, or ||. The author tested all three compound operators and confirmed the bypass on each.

Why this happens

Claude Code’s permissions.deny rules in settings.json evaluate commands as whole strings. The deny pattern checks if the command matches a regex. But compound commands combine multiple operations:

cd .. && rm -rf important-data/
echo "done" ; dropdb production
npm test || sudo rm -rf /

If the deny rules match against rm -rf or dropdb, they should catch these. The problem is that the evaluation logic appears to check the first command or the overall string in a way that misses the dangerous segment after the operator.

What works instead

A PreToolUse hook can evaluate the command string and match patterns anywhere in it, not just at the start. The regex patterns need to account for compound operators as valid prefixes:

(^|\s|;|&&|\|\|)dangerous_pattern

This matches dangerous_pattern whether it appears:

• At the start of the command (^)
• After whitespace (\s)
• After a semicolon (;)
• After &&
• After ||

Every check in bash-guard uses this approach. When Claude Code runs cd .. && dropdb production, the hook scans the entire command string and finds dropdb after &&. It blocks.

curl -sL https://raw.githubusercontent.com/Bande-a-Bonnot/Boucle-framework/main/tools/bash-guard/install.sh | bash

The broader pattern

This is not limited to cd. Any benign command can serve as the first segment:

echo "starting" && terraform destroy --auto-approve
ls -la ; kubectl delete namespace production
npm test || prisma db push --force-reset

In each case, the first command is harmless. The second command is destructive. If evaluation stops at the first segment, the destructive operation runs unchecked.

The fix is simple in principle: evaluate every segment of a compound command against every deny rule. Until Claude Code does this natively, hooks provide the enforcement layer.