[BUG] VS Code extension never loads project-scope @skills-dir plugins; Manage Plugins shows them as (suppressed) and writes that placeholder into enabledPlugins

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

A plugin directory under a project's .claude/skills/ (origin @skills-dir) loads correctly in the CLI but never loads in the VS Code extension — same machine, same folder, same Claude Code version (2.1.292 on both sides).

The extension's Manage Plugins dialog lists the plugin with the literal name (suppressed), and its enable toggle persists "(suppressed)@skills-dir": true into enabledPlugins. That key can never match the plugin's real id, so the toggle has no visible effect. Nothing in the panel reports a reason: no error row, no diagnostic.

The same plugin loads in the same extension through the @inline origin, which narrows the defect to @skills-dir handling rather than plugin loading in general.``

What Should Happen?

The extension should load project-scope skills-directory plugins exactly as the CLI does, listing the plugin's skills in the / menu as /my-plugin:hello.

Failing that, it should say why it didn't — and the Manage Plugins entry should carry the plugin's real name, with a toggle that writes that name.

Error Messages/Logs

Steps to Reproduce

Two files are enough. In an otherwise empty folder C:\dev\sample-repo:

.claude/skills/my-plugin/.claude-plugin/plugin.json

{
  "name": "my-plugin",
  "version": "0.1.0",
  "description": "Minimal plugin for reproducing a loading bug."
}

.claude/skills/my-plugin/skills/hello/SKILL.md

---
name: hello
description: Minimal skill that proves the plugin loaded.
---

Say PLUGIN LOADED.

Then:

1. Open C:\dev\sample-repo as the workspace root in VS Code and accept workspace trust.

1. Run claude once in the integrated terminal and accept Claude Code's own trust dialog, so projects["C:/dev/sample-repo"].hasTrustDialogAccepted is true in ~/.claude.json. This step is required and easy to miss: a project-scope skills-directory plugin is skipped until it is done, and VS Code trust inherited from a parent folder does not satisfy it.

1. In that same integrated terminal, type /. The skill is listed as /my-plugin:hello. claude plugin list confirms it:

```
Skills-directory plugins (.claude/skills/*):

> my-plugin@skills-dir
Version: 0.1.0
Scope: project
Path: .\.claude\skills\my-plugin
Status: ✓ loaded
```

1. In the extension's chat panel, start a new conversation and type /my-plugin. The panel answers No matching commands. /reload-plugins reports Reloaded: 0 plugins · 0 skills · 6 agents · 0 hooks · 0 plugin LSP servers. A full window reload does not change this.

1. Open Manage Plugins in the panel. The plugin is listed as (suppressed)@skills-dir, toggle off, with the note Part of it may not be running. Clicking the toggle changes nothing visible; it writes "enabledPlugins": { "(suppressed)@skills-dir": true } to ~/.claude/settings.json, a key that matches no plugin.

(Identifiers substituted — my-plugin, C:\dev\sample-repo; outputs otherwise verbatim.)

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.292

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

On the Terminal/Shell field, I selected "Other". The bug is in the VS Code extension's chat panel, which isn't a terminal and isn't among the options. The VS Code integrated terminal, in the very same window and folder, works correctly — it is the panel that fails, so picking "VS Code integrated terminal" would have pointed at the wrong component.

Bisection. One machine, one folder, one Claude Code version. Only the plugin's origin differs.

| Case | CLI | Extension panel |
|---|---|---|
| Plain project skill, .claude/skills/<name>/SKILL.md | loads | loads |
| Plugin under .claude/skills/ (@skills-dir) | loads | never loads |
| Same plugin via CLAUDE_CODE_PLUGIN_DIRS (@inline) | loads | loads |

Prerequisites ruled out — all satisfied while the panel still failed:

• Workspace trust: "hasTrustDialogAccepted": true recorded for the exact path
• Explicit enablement: "my-plugin@skills-dir": true written by hand into the project's .claude/settings.local.json, confirmed to survive a window reload
• Plugin validity: claude plugin validate passes on both the skills directory and the plugin manifest
• Session freshness: new conversation, /reload-plugins, and a full window reload each tried

Workaround. Load the plugin through the @inline origin instead. In VS Code user settings:

"claudeCode.environmentVariables": [
    { "name": "CLAUDE_CODE_PLUGIN_DIRS", "value": "C:\dev\sample-repo\.claude\skills\my-plugin" }
]

After a window reload the panel lists the plugin's skills normally. The setting is machine-scoped, so the plugin then loads in every project; it can be turned off per project with "my-plugin@inline": false.

Impact. A repository that ships its tooling as a skills-directory plugin works for terminal users and silently does nothing for extension users, with no error and no diagnostic — and the one affordance that looks like a fix is inert. In practice this reads to users as "the extension doesn't support skills", which is how it was first reported to me: by a developer who abandoned the extension for the CLI over it.