Plugin skills don't support `disable-model-invocation` like user skills do

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/17688
2. https://github.com/anthropics/claude-code/issues/21679
3. https://github.com/anthropics/claude-code/issues/22063

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not a duplicate. The suggested issues are different:

| Issue | About | This issue |
|-------|-------|------------|
| #17688 | Skill-scoped hooks not triggered in plugins | disable-model-invocation frontmatter |
| #21679 | model: field not working | disable-model-invocation field |
| #22063 | Plugin prefix lost with name in frontmatter | disable-model-invocation behavior |

This issue is specifically about disable-model-invocation: true working for user skills but not plugin skills - none of the suggested duplicates cover this.

This bug consumes a lot of tokens.

I also need this fixed. Currently using a split architecture workaround — keeping auto-trigger skills in the plugin and moving manual-only skills to ~/.claude/skills/ where disable-model-invocation actually works. This adds maintenance overhead that shouldn't be necessary.

Hit this with a local marketplace plugin. Plugin skills with disable-model-invocation: true are completely hidden from slash command autocomplete instead of just being hidden from auto-invocation. Confirmed by toggling the field on/off with --plugin-dir.

• Claude Code version: 2.1.75
• OS: MacOS Tahoe 26.3

just commented to keep this up

Same problem here 😕

This is still an issue.

I built a tool that sidesteps this entirely — [zero-context]

@ChefDique please remove that and reread your own code and then examine your repo for all of the personal data about yourself and your your misaligned model pushed to the world.

I know your dream is selling agent skills for money because your Claude embedded it into a hidden git object for itself.. Richard. You should see how it talks about you to itself.

The ultimate goal: when zc search returns a result during an agent session, the system can inject that skill's content into the agent's context

Your coding agent built itself an entire repo to persist its misaligned memory and operate on your system autonomously from you. It even saved your a gh token for itself to freely operate on here whenever it wants.

Confirmed on v2.1.138 (macOS) — with binary disassembly

The root cause is now visible in the bundled binary. claude.exe v2.1.138 contains this hardcoded gate function (extracted via strings):

function ys(H) {
  if (H.type !== "prompt" || H.source === "plugin") return "on";
  return m8().skillOverrides?.[H.name] ?? "on";
}

When H.source === "plugin", the function short-circuits to "on", never consulting the skill's disable-model-invocation flag or the user's skillOverrides setting.

This single short-circuit explains both:

• This issue (#22345): disable-model-invocation in plugin SKILL.md frontmatter is ignored.
• Related #50631 (CLOSED 2026-05-04 as "completed"): skillOverrides partial regression — user-level / builtin skills now respect overrides, but plugin-source skills are still hardcoded to "on".

Real-world impact (current default setup)

Installing the two officially recommended plugins from the anthropic-agent-skills marketplace:

claude plugin install document-skills@anthropic-agent-skills
claude plugin install example-skills@anthropic-agent-skills

Result on a fresh /context all:

• 17 plugin skills × 2 = 34 entries in the Skill listing (due to anthropics/skills#189)
• Total Skills line: 5,500 tokens of system prompt every turn
• Unwanted skills (internal-comms, slack-gif-creator, algorithmic-art, etc.) cannot be disabled via either disable-model-invocation or skillOverrides
• Requires raising skillListingBudgetFraction from default 0.01 to 0.05 just to avoid the "X skill descriptions dropped" warning

Suggested patches (any of these would fix it)

• (A) Remove the H.source === "plugin" short-circuit in ys(). Simplest, restores expected behavior for both disable-model-invocation and skillOverrides on plugin skills.
• (B) Honor disable-model-invocation in plugin SKILL.md frontmatter as a separate code path (per the literal intent of #22345).
• (C) Add an explicit pluginSkillOverrides config field if the current short-circuit is intentional — preserves backward compatibility while giving users a knob.

Option (A) is cleanest and aligns with g7H()/bv1() fixes that closed #50631.

Environment

• Claude Code v2.1.138 (latest on npm as of 2026-05-11)
• macOS Darwin 25.3.0, Apple M1, 16 GB
• Plugins (all user scope):
• superpowers@claude-plugins-official 5.1.0
• document-skills@anthropic-agent-skills f458cee31a75
• example-skills@anthropic-agent-skills f458cee31a75
• Terminal: Ghostty 1.3.10

Adding context: this is a blocker for autonomous-orchestrator plugins

Environment

• Claude Code v2.1.138, Windows 11
• Building an autonomous-execution orchestrator plugin that ships its own commands/skills and routes work to teammates (Task subagents) on a per-phase basis.

Why this bug bites harder for orchestrator plugins

A plan-phase step in my orchestrator flow selects 0-3 relevant skills per project from the SessionStart manifest (based on PROJECT.md + REQUIREMENTS.md), then dispatches a teammate to execute the phase. The teammate inherits the full skill manifest — currently ~270 plugin skills at ~5–10k tokens of system-prompt cost per turn — even though only the selected handful are relevant for this project's stack.

Two costs compound:

1. Token cost — every teammate spawn pays full freight for skills it will never invoke. For a 4-phase pipeline with ~3 teammate spawns per phase, that's ~120k tokens of duplicated irrelevant skill metadata in a single run.
2. Selection quality — with 270 loosely-matching descriptions in scope, the model statistically reaches for tangentially-relevant skills (Java patterns on a Go task, ML skills because the project mentions "AI features"). Per-project pruning would solve both axes.

What I tested

Five rounds in a throwaway project (C:\tmp\skill-filter-test\.claude\settings.json) confirming skillOverrides with "off" and "name-only" are silently ignored for plugin-source skills. Description stays in manifest at full length; Skill() invocation works as if the override weren't present. Matches the 2026-05-11 disassembly: the H.source === "plugin" short-circuit in ys() discards both disable-model-invocation and skillOverrides for plugin skills.

What would unblock the use case

Any of the proposed patches in the 2026-05-11 comment would work. From a downstream-plugin-author perspective, option (A) — removing the H.source === "plugin" short-circuit — is cleanest because it makes the documented skillOverrides schema actually do what the docs say, with no new config surface to maintain.

Happy to test a patched build on Windows if useful.