claude-code - 💡(How to fix) Fix Feature Request: Skill-scoped permissions

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

Skills are the primary mechanism for extending Claude Code with custom workflows. Without skill-scoped permissions, every skill that runs shell commands degrades the user experience — either:

  1. The user is constantly prompted (friction), or
  2. The user grants overly broad global permissions (security risk)

Skill-level trust is a natural mental model: "I trust this skill to do its job."

Fix Action

Fix / Workaround

Current Workaround

Code Example

{
  "permissions": {
    "skills": {
      "update-servers": {
        "allow": ["Bash(*)", "Read(/tmp/*)"]
      }
    }
  }
}

---

---
name: update-servers
description: Updates remote servers via SSH
permissions:
  allow:
    - "Bash(ssh *)"
    - "Bash(bash /tmp/update-servers-*.sh)"
    - "Read(/tmp/update-*.log)"
---
RAW_BUFFERClick to expand / collapse

Problem

Claude Code's permission system only allows global or project-level allow/deny rules for tools and Bash commands. There is no way to scope permissions to a specific skill.

When a user trusts a skill (e.g., /update-servers) to perform its job — SSH into known hosts, write temp scripts, read log files — they must manually enumerate every command pattern in settings.json. This is:

  • Fragile: Any variation in command format (compound commands, different flags) breaks the match
  • Tedious: The user must know in advance every Bash pattern the skill will use
  • Counterintuitive: Users think in terms of skills, not individual tool calls

Desired Behavior

Allow permissions to be scoped to a named skill:

{
  "permissions": {
    "skills": {
      "update-servers": {
        "allow": ["Bash(*)", "Read(/tmp/*)"]
      }
    }
  }
}

Or alternatively, allow skills to declare their required permissions in SKILL.md frontmatter:

---
name: update-servers
description: Updates remote servers via SSH
permissions:
  allow:
    - "Bash(ssh *)"
    - "Bash(bash /tmp/update-servers-*.sh)"
    - "Read(/tmp/update-*.log)"
---

The user would be asked once (at skill invocation or installation) to approve the declared permissions, similar to how mobile apps request permissions.

Why This Matters

Skills are the primary mechanism for extending Claude Code with custom workflows. Without skill-scoped permissions, every skill that runs shell commands degrades the user experience — either:

  1. The user is constantly prompted (friction), or
  2. The user grants overly broad global permissions (security risk)

Skill-level trust is a natural mental model: "I trust this skill to do its job."

Current Workaround

Manually adding pattern rules to settings.json for every command the skill might run — a brittle, incomplete solution that breaks when the skill uses compound commands or argument variations that don't match the glob.

Environment

  • Claude Code CLI
  • Skills system (user-defined SKILL.md files)

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Feature Request: Skill-scoped permissions