[BUG] Project-scoped plugin installs (--scope project) load in CLI sessions but are silently ignored by the VS Code extension

Open 💬 2 comments Opened Jul 5, 2026 by dan-1492

Environment

  • Claude Code CLI: v2.1.198 (Windows 11)
  • VS Code extension: anthropic.claude-code v2.1.201
  • Plugin: superpowers@claude-plugins-official v6.1.1 (official Anthropic marketplace)

Steps to reproduce

  1. From a workspace folder, run: claude plugin install superpowers@claude-plugins-official --scope project
  2. Observe it succeeds: "enabledPlugins": {"superpowers@claude-plugins-official": true} is written to the workspace's .claude/settings.json, and ~/.claude/plugins/installed_plugins.json gains a "scope": "project" entry with the correct projectPath. claude plugin list shows it enabled.
  3. In a terminal CLI session launched from that workspace (e.g. claude -p "invoke the skill superpowers:using-superpowers"): the plugin's skills ARE registered and invocable. Works as documented.
  4. In a VS Code extension session in that same workspace, after a full VS Code shutdown and restart: the plugin's skills are NOT registered. Namespaced invocation returns Unknown skill: superpowers:using-superpowers, and no superpowers:* entries appear in the available-skills list.

Key evidence that this is plugin-specific, not settings loading

In the same extension session that fails to register the plugin:

  • An env var added to the same project .claude/settings.json file in the same edit (SUPERPOWERS_DISABLE_TELEMETRY=1) IS applied. So the extension reads and honors the project settings file; it specifically does not honor the plugin enablement.
  • User-scoped plugins' skills all register normally in the extension session.
  • The failure survives a full VS Code shutdown (genuinely new process, verified via the fresh env application above).

Expected

A plugin installed with --scope project behaves the same in every session type launched from that project: CLI and VS Code extension.

Actual

CLI sessions honor the project scope; VS Code extension sessions silently ignore it (no error, no warning; the plugin is just absent).

Why this is distinct from #62174

#62174 (closed as not planned) asked for per-project enabledPlugins as a feature. This report is about an inconsistency between two shipped surfaces: the CLI ships and honors a --scope project install flag today, and the extension ignores its result. Either the extension should honor project-scoped installs, or the CLI should not offer the flag / should warn that extension sessions won't see it. The current state is a silent divergence that costs users a debugging session to discover.

Impact

Any workflow that uses project scoping to keep a plugin's skills out of unrelated projects (the documented purpose of the scope flag) breaks for VS Code extension users with no signal. In our case: a plugin adoption plan built on project isolation had to fall back to "plugin available in terminal sessions only" after tracing the discrepancy.

View original on GitHub ↗

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