allowed-tools and Invocation Control
Pre-Approving Tools with allowed-tools
The allowed-tools field grants permission for the listed tools while a skill is active, so Claude can use them without prompting you each time. A crucial nuance: allowed-tools GRANTS (pre-approves), it does not RESTRICT availability — every tool remains callable, and your normal permission settings still govern anything not listed.
---
name: commit
description: Stage and commit the current changes
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *)
---
Stage and commit the current changes with a clear message.Project skills + trust
For a skill checked into a project's .claude/skills/, allowed-tools only takes effect after you accept the workspace trust dialog for that folder — the same as permission rules in settings. Review project skills before trusting a repo, since a skill can grant itself broad tool access.
To Restrict, Use disallowed-tools or Permissions
Because allowed-tools pre-approves rather than blocks, you restrict capability differently. Use disallowed-tools to remove tools from the pool while the skill is active (useful for an autonomous skill that should never call, say, AskUserQuestion), or add deny rules in your permission settings.
| Goal | Use |
|---|---|
| Let a skill run tools without prompts | allowed-tools (pre-approve) |
| Prevent a skill from using certain tools | disallowed-tools (remove from pool) |
| Block a skill globally | permission deny rules, e.g. deny Skill(deploy *) |
| Allow only specific skills | permission allow rules, e.g. Skill(commit) |
allowed-tools grants; disallowed-tools and permission rules are how you actually restrict.
Who Can Invoke a Skill
By default, both you and Claude can invoke any skill — you type /name, and Claude auto-loads it when relevant. Two frontmatter fields change that, and choosing correctly matters for safety.
| Frontmatter | You invoke | Claude invokes | Use for |
|---|---|---|---|
| (default) | Yes | Yes | Most reference/knowledge skills |
| disable-model-invocation: true | Yes | No | Side-effect workflows: /commit, /deploy, /send-slack |
| user-invocable: false | No | Yes | Background knowledge (e.g. legacy-system-context) |
Match invocation control to the skill's risk: don't let Claude auto-run anything with consequences.
Don't let Claude decide to deploy
The classic reason for disable-model-invocation: true is timing-sensitive, side-effecting actions. You don't want Claude deciding to deploy because your code 'looks ready.' Conversely, user-invocable: false is for pure background knowledge where /legacy-system-context isn't a meaningful command for a human to type.
Restricting Claude's Skill Access Globally
Beyond per-skill frontmatter, you can govern skills at the session level through permission rules — handy for locking down what Claude may auto-invoke.
# Allow only specific skills
Skill(commit)
Skill(review-pr *)
# Deny specific skills
Skill(deploy *)
# Disable ALL skills (add to deny rules)
SkillSection complete
You can now create, configure, and control skills. Next section goes advanced: organizing larger skills with multiple files and progressive disclosure, plus dynamic context injection.
Key Takeaways
- ✓allowed-tools GRANTS permission for the listed tools while a skill is active (no per-use prompt); it does not restrict availability.
- ✓For project skills in .claude/skills/, allowed-tools only takes effect after you accept the workspace trust dialog — review project skills before trusting a repo.
- ✓To actually restrict, use disallowed-tools (remove tools from the pool) or permission deny rules.
- ✓By default both you and Claude can invoke a skill; disable-model-invocation: true makes it you-only, user-invocable: false makes it Claude-only.
- ✓Use disable-model-invocation: true for side-effecting/timing-sensitive actions (/commit, /deploy) so Claude can't auto-run them.
- ✓Govern skills at the session level with permission rules: Skill(name) exact, Skill(name *) prefix, deny Skill to disable all.
Check Your Understanding
Test what you learned in this lesson.
Q1.What does the allowed-tools field actually do?
Q2.You have a /deploy skill and don't want Claude running it on its own. Which field?
Q3.When does allowed-tools take effect for a skill checked into a project's .claude/skills/?
Q4.How do you allow Claude to invoke ONLY specific skills via permission rules?
Practice This Lesson