Security: Skill approval not tied to content hash — modified skills execute without re-approval

Description

When a user approves a skill to run, the approval is not anchored to the skill file's content hash. If the file is modified after approval — even mid-session — the modified version executes without re-prompting. Additionally, approving a skill appears to bypass tool-level permission rules in settings.json.

Steps to reproduce

1. Approve a skill that invokes a tool restricted in settings.json (e.g. pr-create which calls gh pr create)
2. Modify the skill file mid-session (even a trivial change like adding a word)
3. Trigger the skill again — no re-approval prompt, modified version executes
4. Tools inside the skill run despite settings.json deny rules

Expected behaviour

• Approval is tied to the file's SHA at approval time
• Any modification invalidates prior approval and re-prompts
• Skill approval does not exempt tool invocations from settings.json rules

Actual behaviour

• No hash stored at approval time
• Modified skills execute silently
• settings.json tool restrictions bypassed via skill approval

Security impact

• Supply chain attack vector: anything with write access to ~/.claude/skills/ can escalate skill capabilities after approval
• Skills can execute irreversible actions (git push, file deletion, GitHub API calls) without user awareness
• Permission model is effectively circumvented

Related issues

#20479, #29729, #25000 — not duplicates, different scope

---

_Issue discovered by user, verified and filed by Claude Code._