Skill allowed-tools grants not applied when the model invokes the skill via the Skill tool

Environment

• Claude Code version: 2.1.172
• Platform: Linux (Fedora-based)
• Terminal: interactive CLI session

Description

allowed-tools in a skill's frontmatter pre-approves the listed tools when the user invokes the skill by typing /skill-name, but the grants are not applied when the model invokes the same skill via the Skill tool — every listed tool prompts for approval.

The skills docs say the grants should apply in both cases:

Skills that define allowed-tools grant Claude access to those tools without per-use approval when the skill is active.

(That sentence is in the "Restrict Claude's skill access" section, which is specifically about model-invoked skills.)

Reproduction

Project skill at .claude/skills/ship/SKILL.md:

---
description: Ship the current branch — rebase on main, push, and open a PR. Use when the user says "ship", "PR this", or "open a PR".
allowed-tools:
  - Bash(git *)
  - Bash(gh *)
  - Bash(.claude/skills/ship/scripts/ship.sh *)
  - Bash(*.claude/skills/ship/scripts/ship.sh *)
model: haiku
---

The skill body instructs running .claude/skills/ship/scripts/ship.sh detect.

Project .claude/settings.json:

{
  "permissions": {
    "allow": ["Skill(ship)"]
  }
}

Workspace trust is accepted. There are no other permission rules for these commands in any settings file.

Steps (same session, back to back):

1. Type /ship → the skill runs ship.sh detect, ship.sh changed-files, git add/commit, ship.sh push, and gh pr — zero permission prompts. ✅
2. Type plain ship → the model calls Skill(ship). The tool result shows the frontmatter was loaded correctly (Successfully loaded skill · 4 tools allowed · claude-haiku-4-5-20251001). The very first command, .claude/skills/ship/scripts/ship.sh detect, triggers the approval dialog ("This command requires approval"). ❌

Since both runs are in the same session with identical frontmatter (and the Skill invocation itself is auto-allowed by the Skill(ship) rule), the only variable is the invocation path.

Expected behavior

Per the docs, the allowed-tools grants apply while the skill is active regardless of whether the user or the model invoked it.

Actual behavior

Grants apply only for user-typed /skill-name invocation. Model invocation via the Skill tool falls back to normal permission prompting for every command, including ones explicitly listed in allowed-tools.

Notes

If this is deliberate hardening (a prompt-injected model invoking a skill to inherit its grants is a plausible concern), the docs should say so — right now they state the opposite. If it's not deliberate, it makes "say the trigger word" skill invocation (encouraged via the description field) noticeably worse than typed invocation for any skill that wraps its own scripts.

---

🤖 Filed with Claude Code on behalf of the user after reproducing the behavior in-session.