fix: allow installed plugin skills to execute in headless runs#1467
Open
Sammy-Dabbas wants to merge 1 commit into
Open
fix: allow installed plugin skills to execute in headless runs#1467Sammy-Dabbas wants to merge 1 commit into
Sammy-Dabbas wants to merge 1 commit into
Conversation
Plugin skills that declare extra capabilities in their frontmatter are auto-denied by the CLI's permission system in headless runs, so prompts asking Claude to run a skill from an installed plugin fail with Error: Execute skill: <name>. Derive Skill(<plugin>:*) allow rules from the plugins input and merge them into allowedTools in both entrypoints. Installing a plugin is an explicit opt-in by the workflow author. Fixes anthropics#1458.
1 task
simonheimlicher
added a commit
to outcomeeng/gh-actions
that referenced
this pull request
Jul 6, 2026
Opting into project plugins installs skills whose frontmatter declares allowed-tools, which the pinned claude-code-action denies in headless runs because it grants no Skill rule for installed plugins. Document the Skill(<plugin>:*) allowlist workaround and the upstream fix (anthropics/claude-code-action#1467) that retires it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1458.
When a workflow installs plugins via the plugins input and the prompt asks Claude to run one of their skills, the run fails with Error: Execute skill: . The cause is permissions rather than installation: headless runs cannot answer permission prompts, and a plugin skill that declares extra capabilities in its frontmatter (for example allowed-tools) is auto-denied when the model invokes the Skill tool, because the action never granted Skill rules for the plugins it just installed. I reproduced this deterministically with a local test plugin and a mock API server against the pinned CLI: the Skill call returns a permission denial with exactly the reported error.
One note on the version bound in the report: fad22eb only bumps the pinned CLI version and the same repro also fails on 2.1.195, so the boundary likely reflects the newer CLI's default model invoking skills through the Skill tool more often, rather than an action code change.
The fix derives Skill(:*) allow rules from the plugins input and merges them into allowedTools in both entrypoints. Installing a plugin is already an explicit opt-in by the workflow author, the same trust the action extends by enabling project MCP servers. User-provided allowed_tools and claude_args values are unaffected since parse-sdk-options merges rather than overwrites.
Tests: nine new unit tests for the rule derivation (failing without the fix), full suite passes, typecheck and prettier clean. Also verified end to end through runClaude() against the pinned CLI: before the fix the skill invocation returns is_error with the reported message, after it the skill launches with no permission denials.