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

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The permissions system requires users to know opaque internal tool names (e.g., TaskStop), but provides no way to discover them. Users who enter incorrect or partial names (e.g., "Stop Task", "stop", "kill-task") get no error, no warning, no suggestion — the rule simply does nothing.
Concretely: /permissions presents human-readable display names like "Stop Task" in its UI, but the underlying runtime matches deny rules against internal function names like TaskStop. A user adding a deny rule for "Stop Task" via the UI will see the rule saved — but it will never fire, because the display name does not match the internal name.

What Should Happen?

The core problem is: the permission system’s input surface is unvalidated and opaque. Users cannot discover valid tool identifiers, and invalid input fails silently. Any fix should address at least the minimum tier:
Minimum (validation):
When a deny rule matches no known tool name, the system should surface an error and list all valid tool identifiers. A developer writing "stop" naturally expects fuzzy matching to TaskStop — currently they get silent failure.
Better (discovery):
Provide a --list-tools flag or API endpoint so users and scripts can dynamically retrieve the canonical tool identifier list.
Ideal (ergonomics):
Support fuzzy matching, prefix matching, or accept the human-readable display names and description fields as aliases for tool identification.

Error Messages/Logs

Steps to Reproduce

1. Run /permissions → add a deny rule for "Stop Task".
2. Verify the rule appears in settings.
3. Ask Claude to stop a background task.
4. Claude successfully calls TaskStop — the deny rule does not block it.
5. Run /permissions again → add a deny rule for "TaskStop" (the internal name, discovered by trial‑and‑error).
6. Now TaskStop is correctly blocked.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.158

Platform

Other

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

This is not an isolated confusion. Other developers have assumed natural names like "stop" would map to TaskStop because the UI shows "Stop Task". The silent failure caused a real user loss: a 40‑minute cold‑start process was killed because the developer thought they had blocked "stop" but no error or fallback existed.
The /permissions UI already knows the human‑readable names — it should either accept those as aliases or at least warn when a rule is added that will never match.