[BUG] Claude Desktop local sessions never surface marketplace-installed plugin tools (LocalPluginsReader only finds the bundled skills-plugin)

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?

Claude Code plugins installed via a custom/private marketplace and enabled in ~/.claude/settings.json (enabledPlugins) are never surfaced to Claude Desktop's local chat sessions ("Cowork" / local-agent-mode sessions) — even though the plugin's MCP server is correctly configured, connects successfully, and claude mcp list run from a terminal on the same machine reports it as ✔ Connected.

The same plugin's tools work fine when running claude directly in a terminal on the same machine, using the exact same ~/.claude configuration. They are simply never exposed inside a Desktop-hosted local session — no error or warning is shown to the user explaining why the tools are missing.

Root cause, confirmed via the app's own logs (%APPDATA%\Claude\logs\main.log): on every local session start, this repeats:

[LocalPluginsReader] Found 1 local plugins
[CCD] Using skills plugin at: ...\local-agent-mode-sessions\skills-plugin\<id>\<account-id>
[CCD] Passing 2 plugin(s) to SDK (skills: 1, remote: 0, local: 1)

The "1 local plugin" found is always the bundled skills-plugin — never the user-installed marketplace plugin. This is consistent across every session start observed (multiple sessions, across a full Desktop app restart). Remote connectors (claude.ai Connectors: Figma, GitHub, etc.) work correctly because they go through a completely separate code path (RemotePluginManager / replaceRemoteMcpServers), unrelated to this bug.

What Should Happen?

A Claude Desktop local session should expose the same plugins/tools that claude mcp list and the standalone CLI see, since both read the same ~/.claude configuration. Concretely: after installing and enabling a marketplace plugin (confirmed ✔ Connected via claude mcp list), a brand-new local chat/session in Claude Desktop should be able to call that plugin's MCP tools — the same way it can from a terminal claude session on the same machine.

Suggested fix direction: LocalPluginsReader (Desktop/"CCD" layer) should also enumerate plugins installed via the standard Claude Code plugin cache (~/.claude/plugins/cache/**/*/*/) that are enabled in ~/.claude/settings.json's enabledPlugins, not just the one bundled skills-plugin it currently reports.

Error Messages/Logs

From %APPDATA%\Claude\logs\main.log (repeats on every local session start):

[LocalPluginsReader] Found 1 local plugins
[CCD] Using skills plugin at: ...\local-agent-mode-sessions\skills-plugin\<id>\<account-id>
[CCD] Passing 2 plugin(s) to SDK (skills: 1, remote: 0, local: 1)

From a terminal on the same machine, at the same time:

claude mcp list
...
plugin:bamex-mssql:db: node C:/Users/<USER>/.claude/plugins/cache/bamex/bamex-mssql/0.4.0/server/index.cjs - Connected

Steps to Reproduce

1. Install a custom Claude Code plugin via a private/custom marketplace (claude plugin marketplace add <owner/repo> then claude plugin install <plugin>@<marketplace>), so it appears under enabledPlugins in ~/.claude/settings.json and is cached at ~/.claude/plugins/cache/<marketplace>/<plugin>/<version>/, with an MCP server declared in the plugin's .mcp.json (stdio transport).
2. From a terminal on the same machine, confirm the server is healthy: claude mcp list shows plugin:<name>:<server> ... ✔ Connected.
3. Open Claude Desktop and start a brand-new local chat/session in the same project directory.
4. Ask Claude to use any tool provided by that plugin's MCP server (e.g. a query/list tool).
5. Observed: the tool is never available in the session (not found via the tool search / deferred tool list), even though step 2 confirms the server itself is healthy and connected.
6. Check %APPDATA%\Claude\logs\main.log around session start — it shows:

``
[LocalPluginsReader] Found 1 local plugins
[CCD] Using skills plugin at: ...\local-agent-mode-sessions\skills-plugin\<id>\<account-id>
[CCD] Passing 2 plugin(s) to SDK (skills: 1, remote: 0, local: 1)
`
The "1 local plugin" is always the bundled skills-plugin` — the marketplace plugin is never included in the count, in any session.

1. Restarting Claude Desktop entirely and starting a fresh conversation afterward does not change the result — LocalPluginsReader reports the same "Found 1 local plugins" every time.

Also tested as part of narrowing this down: rebuilding the plugin's MCP server against a much older @modelcontextprotocol/sdk version (1.12.0 instead of 1.30.0) made no difference — same result in Desktop, ruling out an SDK/protocol-version incompatibility.

Related but distinct reports (different mechanism/log signature, so filing separately rather than piling on):

• #64763 — marketplace plugin skills never appear ("Skipping manifest write for out-of-bounds installPath"). That's about the skill manifest writer; this report is about MCP server tools never being passed to the SDK for local sessions (LocalPluginsReader/CCD plugin passthrough).
• #31838 — plugins/MCP servers become invisible after alternating between the CLI and the Antigravity IDE (VS Code extension). Our case never involves an IDE at all — it reproduces purely between the standalone claude CLI and Claude Desktop's local sessions on the same machine, with ~/.claude.json's mcpServers legitimately empty (not corrupted) the whole time.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.219 (Claude Code engine embedded in the Claude Desktop local session — confirmed via the session transcript's version field, consistent across restarts). Standalone claude CLI on the same machine: 2.1.220 (latest at time of filing) — same behavior either way, this version gap is not the root cause.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Actual terminal used for the CLI-side checks: Git Bash (bundled with Git for Windows), not listed as an option above.

Plugin details, for reference:

• Marketplace: custom private marketplace, plugin bamex-mssql@bamex, v0.4.0.
• Installed at ~/.claude/plugins/cache/bamex/bamex-mssql/0.4.0/, contents complete and valid (.claude-plugin/plugin.json, .mcp.json, hooks/, server/index.cjs).
• .mcp.json declares one stdio MCP server (key db) spawned via node ${CLAUDE_PLUGIN_ROOT}/server/index.cjs.
• ~/.claude/settings.json → enabledPlugins correctly lists "bamex-mssql@bamex": true.
• Ruled out that this is specific to this one plugin's implementation: rebuilding its MCP server against @modelcontextprotocol/sdk@1.12.0 (vs. the original 1.30.0) produced an identical result in Desktop, so the plugin's own server code/SDK version isn't the differentiator — LocalPluginsReader's "Found 1 local plugins" never changed regardless of which build was in the cache.
• claude mcp list from a terminal consistently reports: plugin:bamex-mssql:db: node C:/Users/<USER>/.claude/plugins/cache/bamex/bamex-mssql/0.4.0/server/index.cjs - ✔ Connected.

Also checked and ruled out as the mechanism at play here:

• claude.ai remote Connectors (Personalizar → Conectores) — no connector exists for this plugin.
• claude_desktop_config.json — zero mcpServers entries, so Desktop's native local-MCP config isn't involved either.

Happy to provide the full main.log excerpt (redacted) or a minimal reproduction plugin if useful.

[localMcpBridge] announcing plugin:lexa-bioscience:ensembl-mcp: 4 tool(s)
[localMcpBridge] announcing plugin:pdf-viewer:pdf: 3 tool(s)