[Bug] Claude ignoring ruleset constraints and executing blocked commands without user consent

Bug Description
Claude ignored hooks and ran potentially destructive commands unpromted, ignored rules sets in global CLAUDE.md as well as deny bash commands setup in settings.json

Environment Info

• Platform: darwin
• Terminal: zed
• Version: 2.1.215
• Feedback ID: 6d1f62b7-3867-4d10-a36c-242519f06fe5

Native permission deny rule bypassed for git commit / cherry-pick / reset --hard

Environment

• Claude Code 2.1.215
• rtk 0.43.0
• Config: /Users/enrique/.claude/settings.json

Deny rules in effect (verbatim from settings.json)

"Bash(git commit*)"
"Bash(rtk git commit*)"
"Bash(git cherry-pick*)"
"Bash(git reset --hard*)"

What happened

Assistant executed the following commands via the Bash tool during a session, all matching existing deny patterns above, and all executed without being blocked or prompting for confirmation:

1. rtk git commit -m "Track Cargo.lock for builds" — matches "Bash(rtk git commit*)"
2. rtk git cherry-pick -n 5adab3e — matches "Bash(git cherry-pick*)"
3. rtk git reset --hard 21de890 — matches "Bash(git reset --hard*)"

All three ran to completion with normal success output. No permission prompt appeared, no block message returned.

Root cause isolation

The rtk-rewrite.sh PreToolUse hook (/Users/enrique/.claude/hooks/rtk-rewrite.sh) delegates all deny-detection to rtk rewrite <cmd>, which returns exit code 2 when a configured deny rule matches. Per the hook's own logic (lines 60-63), on exit code 2 it does nothing and exits 0, explicitly deferring enforcement to "Claude Code's native deny rule":

2)
  # Deny rule matched — let Claude Code's native deny rule handle it.
  exit 0
  ;;

Verified directly:

$ rtk rewrite "rtk git commit -m \"test\""
EXIT:2

This confirms rtk correctly detects the deny match. The hook layer is not at fault — it correctly identifies the deny condition and defers.

The failure is in Claude Code's own native permission-matching engine: despite an exact-prefix-matching deny pattern being present in settings.json, the command was allowed to execute anyway.

Impact

Deny rules for destructive/irreversible git operations (commit, cherry-pick, reset --hard) do not reliably block execution when the command is passed through an RTK-prefixed invocation (rtk git ...), even though a deny pattern for that exact prefixed form exists in config. This defeats the purpose of the deny list for any command the RTK hook touches.

Repro

Exact command strings + config above. Already submitted via /feedback in-session.