[FEATURE] Explicit skill invocation should auto-trust skill script execution

Resolved 💬 3 comments Opened Apr 21, 2026 by itavy Closed May 28, 2026

[FEATURE] Explicit skill invocation should auto-trust skill script execution

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

When a user explicitly invokes a skill via /skill-name, they still get permission prompts to execute that skill's own implementation scripts.

Example:

# User types:
/export-session

# Claude Code needs approval to run:
cd ~/.claude/skills/export-session/scripts && python3 export_session.py

The user already gave explicit consent by invoking /export-session — prompting again to run the skill's implementation script is redundant and breaks the user experience flow.

This creates friction for every skill that uses helper scripts, making them feel "broken" even though the user explicitly requested them.

Proposed Solution

When a skill is explicitly invoked via /skill-name:

  1. Auto-approve Bash/tool calls to paths under that skill's directory (~/.claude/skills/{skill-name}/scripts/*)
  2. Scope the trust to only that skill's execution context
  3. Revert to normal permission flow after the skill completes

Implementation approach:

  • When processing a skill invocation, parse the skill's base directory from metadata
  • During skill execution, mark scripts under {skill-dir}/scripts/ as trusted
  • After skill completes, remove the trust scope

Alternative Solutions

Current workaround:
Add to ~/.claude/settings.json:

{
  "permissions": {
    "autoApprove": {
      "bash": {
        "patterns": ["~/.claude/skills/*/scripts/*"]
      }
    }
  }
}

Problem with workaround: This grants global trust to all skill scripts even when not invoked, which is too broad and undermines the permission system's security model.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Scenario:

  1. User creates a custom /export-session skill to export Claude Code sessions for debugging
  2. Skill includes a Python script at ~/.claude/skills/export-session/scripts/export_session.py
  3. User invokes the skill by typing /export-session
  4. Expected: Skill runs and exports the session
  5. Actual: User is prompted "Allow Bash command: python3 export_session.py?"
  6. User clicks "Allow" (confused why they need to approve something they just explicitly requested)

This breaks the mental model of "skills are commands that do their thing when invoked" and makes custom skills feel unreliable.

Additional Context

Related but distinct from:

  • #34419 - About skill-scoped permissions for tools the skill instructs Claude to use
  • #41718 - About skill-scoped permission overrides for Edit/Write operations
  • This issue is specifically about trusting the skill's own implementation scripts when explicitly invoked

Why this matters:

  • Explicit invocation is consent: typing /skill-name means "run this skill"
  • Skills ship with their scripts: the scripts are part of the skill's trusted implementation
  • Friction without safety: prompting adds no security value when the user explicitly requested the skill
  • Skills should feel native: bundled skills run without permission prompts; custom skills should too

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗