[FEATURE] Support permissions scopes for custom skills.
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Custom slash commands can be made to apply a consistent approach to a repeated problem. Due to their deterministic and constrained nature, these tasks may have more leeway with actions Claude can take. This means that required permissions for these tasks can be predicted and therefore pre-approved.
Currently however, when running a custom skill that predictably needs specific tool access (e.g., a code migration command that always needs to run linters, tests, build and execute steps), users face two bad options:
- Globally allow the commands in
settings.json— grants permissions to every session, not just the skill that needs them - Manually approve each prompt — tedious and repetitive for skills that are run frequently and always need the same permissions
Custom slash commands (.claude/commands/*.md) currently have no way to declare tool permissions that should be pre-approved for the duration of that command's execution. There's no middle ground for "allow this specific tool usage, but only for this skill execution".
Proposed Solution
Allow command markdown files to declare scoped permissions via frontmatter, e.g.:
---
allowed_commands:
- Bash(npm run build)
- Bash(npm test *)
- Bash(grep -r *)
- Bash(find . -name *)
- Bash(npm run migrate)
---
Perform the migration as described below...
These permissions would:
- Be active only for the duration of the slash command execution
- Not persist after the command completes
- Not affect global
settings.json - Still be visible to the user (e.g., shown when the command starts, or listed in
/help)
Alternative Solutions
- Temporarily editing
settings.jsonbefore/after running a skill (fragile, easy to forget cleanup) - Globally allowing all commands a skill might need (overly broad)
- Manually approving every prompt (repetitive for well-understood skills) - Current solution, safest.
Priority
Medium - Would be very helpful
Feature Category
CLI commands and flags
Use Case Example
Current State:
- Workflow:
- A skill to execute a code review exists.
- The skill utilises GitHub CLI tools to fetch and read PRs.
- GitHub CLI is capable of far more than just read and requires detailed assessment for what commands are safe to allow globally
- With no global allows, execute the skill, manually review each permission request for command execution.
- Outcomes:
- Potential for decision fatigue or allowing global permissions to be added that can be exploited or mistakenly used.
- Slower execution of the skill due to the attention requirements reducing agentic autonomy.
Future State:
- Workflow:
- A skill to execute a code review exists.
- The skill has scoped permissions determined at the time of skill creation for exact usage that the skill requires.
- The permission is either approved or a warning is provided at the start of skill execution.
- The skill continues its execution only requesting for permissions for any anomalies.
- Outcomes:
- User is not prompted during execution for expected flows.
- Permissions are visible for each skill and if users prefer can remove them to ensure they are asked if that is the preference.
- Transition of skills to plugins is smoother and more self contained.
- Tool checks and validation can be done ahead of time to validate the user system contains these tools.
Additional Context
_No response_
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗