[BUG]Permissions system requires internal tool names (TaskStop) that are not discoverable; invalid names fail silently

Confirming this from the matching side, and adding a discovery method that works today.
Why the silent failure happens. Permission rules match against the canonical tool identifier (the name field in the tool-use protocol, e.g. TaskStop, Bash, Read), with no alias table and no fuzzy/prefix matching. The /permissions UI shows the human-readable label ("Stop Task"), but the runtime only ever compares your rule string to the canonical name. So a Stop Task deny rule is saved, validates as well-formed, and silently never fires — exactly your repro. There is no place in the flow where "this rule will never match any known tool" is detected, so I agree the missing validation tier is the real bug.
Discovery that already works (no trial-and-error needed). The canonical names the matcher uses are written to your session transcript. Every time a tool runs, the JSONL records a tool_use block whose .name is the exact identifier deny matches against. So you can recover the correct string by running the tool once, then grepping the transcript:

grep -ho '"type":"tool_use"[^}]*"name":"[^"]*"' \
  ~/.claude/projects/*/*.jsonl | grep -o '"name":"[^"]*"' | sort -u

On my machine this returns the literal strings (Bash, Read, Edit, TaskStop, AskUserQuestion, Skill, …) — i.e. the values a deny rule has to match character-for-character. That turns "guess until it fires" into "look it up". A --list-tools flag would still be the right fix, but the data is already there in the logs.
For the destructive-loss case specifically (the 40-min cold start that got killed): the dangerous property is that a UI-label rule fails silently — you only learn it didn't bind after the loss. A PreToolUse hook is keyed on the same canonical name programmatically, so besides being able to block (exit 2), it can also log every time it fires and every time it sees a tool it doesn't recognize — which makes a mis-keyed rule visible before it costs you something, instead of after. A few lines in settings.json:

{ "hooks": { "PreToolUse": [
  { "matcher": "TaskStop",
    "hooks": [ { "type": "command",
      "command": "echo \"[blocked TaskStop] $(date)\" >> ~/.claude/deny.log; exit 2" } ] }
]}}

Because the matcher runs on the canonical tool name (the same string from the transcript), there's no display-name mismatch, and the log line tells you it actually engaged.

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/29694
2. https://github.com/anthropics/claude-code/issues/57091

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Thanks for closing this and confirming the bug!

One follow-up: could you confirm whether the /permissions dialog and/or the permissions docs page will be updated alongside the fix? The worry is that even after the code fix ships, future users will still face the same silent-failure pitfall unless:

• The /permissions UI shows canonical tool names (or accepts display names as aliases), OR
• The docs page provides a discoverable list of valid tool identifiers.

A grep-on-JSONL workaround is useful for power users, but the average user who sees "Stop Task" in the UI should not need to mine session transcripts to write a working deny rule.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.