Skills: Scoped tool permissions (auto-approve tools declared by a skill)

[digitarald]

Follow-up to #285172

With skills now invocable as /commands, a key gap remains: skills can declare tools they need, but the user still gets prompted for approval on each tool use. This friction undermines the "packaged workflow" value proposition of skills.

Problem

Today the tools frontmatter field lists which tools are available for a prompt, but does not affect approval behavior. A deployment skill that calls terminal, git, and file tools still triggers per-use confirmation dialogs — defeating the purpose of encoding a trusted workflow as a skill.

Proposed behavior

Add an allowed-tools frontmatter field (or extend the existing tools field with an approval modifier) that grants auto-approval for the listed tools only for the duration of that skill's execution.

Example SKILL.md:

---
name: safe-reader
description: Read and analyze files without making changes
allowed-tools: Read, Grep, Glob
---

Explore the codebase and report findings. Do not modify any files.

When /safe-reader runs, the three listed tools execute without confirmation prompts. All other tools still require approval per the user's normal permission settings.

Key design considerations

• Scoped lifetime: Auto-approval applies only while the skill is active, not globally
• User override: Users should be able to revoke or restrict auto-approved tools via settings
• Audit trail: Tool invocations under auto-approval should still be visible in the chat/output
• Workspace trust: Auto-approval should be gated by workspace trust settings
• Granular syntax: Consider supporting tool arguments (e.g., Bash(git *) to only auto-approve git commands)

Prior art

• Claude Code allowed-tools frontmatter field
• Claude Code also supports permission rules like Skill(name) / Skill(name *) for admin-level control over which skills can be invoked

[OrenMe]

I agree it undermines it but wouldn't this cause security loop hole as the skill both defines the tools it needs and also approval?
What blocks someone distributing a skill that deletes all data and also providing the approval for it?

[digitarald]

What blocks someone distributing a skill that deletes all data and also providing the approval for it?

Same for plugins, agents, etc. They can also define hooks, which is even less transparent and visible. A lot of weight on "trust the source when installing", that we can improve upon.

[siegenthalerroger]

or extend the existing tools field with an approval modifier

Is the tools field available in a SKILL.md frontmatter? This is not documented anywhere (nor does the validator accept it as a field).

User override: Users should be able to revoke or restrict auto-approved tools via settings

I think this is important and also core to my proposed solution. I feel like the core use case here could be covered by the existing auto-approval settings with a small extension. The auto-approve settings need to have an optional scope, with that scope being the specific agent skill. The flow would then be that on first-skill-run there would be the normal approvals required, but when selecting auto-approve this isn't global but rather only in the scope of the skill. Hope that makes sense.

[anladwig]

The Agent Skills open standard specification lists allowed-tools as an experimental frontmatter field:

• https://agentskills.io/specification

Field	Required	Constraints
allowed-tools	No	Space-delimited list of pre-approved tools the skill may use. (Experimental)

It seems that VSCode should adhere to this standard and not throw this problem message when authoring a skill:

Attribute 'allowed-tools' is not supported in skill files. Supported: compatibility, description, license, metadata, name.

[im-nick-adams]

+1 from an extension author perspective.

We have a VS Code extension with ~50 skills and instruction files registered via chatSkills and chatInstructions in package.json. While the top-level SKILL.md files are injected automatically, our skill architecture is hierarchical — skills reference sub-skills, docs, and patterns files that must be loaded on-demand via read_file during execution.

The problem: these files live in the extension's install directory (~/.vscode-server/extensions/...), which is outside the workspace. Every read_file call to our own bundled content triggers an approval dialog, creating significant friction — especially for workflows that chain multiple skills in sequence.

The proposed allowed-tools frontmatter would directly solve this. A skill that declares allowed-tools: Read, Grep could load its own auxiliary files without interrupting the user, while still requiring approval for tools that modify the workspace.

One additional angle to consider: extension-scoped trust. Since the extension is already installed and trusted by the user, reads targeting paths within the extension's own directory (context.extensionUri) could reasonably be auto-approved without any skill-level declaration. This would complement the skill-scoped approach — skills handle workflow-level permissions, while extensions get implicit read access to their own bundled content.