--plugin-dir loads plugin skills but never starts the plugin's MCP servers (desktop app sessions lose all plugin MCP tools)

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 that bundles an MCP server works fully when Claude Code resolves it through normal plugin resolution (installed from a marketplace, enabledPlugins), but when the same plugin directory is passed via --plugin-dir, its skills load and its MCP servers silently never start — no tools, no error. Passing --plugin-dir for a plugin id that is also installed normally additionally suppresses the installed copy, so the tools disappear entirely.

The Claude desktop app launches every session with --plugin-dir flags (one per enabled plugin, pointing at ~/.claude/plugins/cache/...), so every desktop-app session — the Claude Code desktop surface and local Cowork — loses all plugin MCP tools, while the same plugin works fine in a terminal.

Captured command line of a desktop-app session's runtime process:

...\claude-code\2.1.221\claude.exe --output-format stream-json ... --permission-prompt-tool stdio
  --setting-sources=user,project,local --permission-mode auto ...
  --plugin-dir C:\Users\<u>\.claude\plugins\cache\claude-plugins-official\claude-md-management\1.0.0
  --plugin-dir C:\Users\<u>\.claude\plugins\cache\tao-internal\ado-mcp\0.3.0
  --settings {}

The plugin in question declares a remote SSE server in .mcp.json; #85623 reports the same symptom signature (skill loads, MCP tools don't, desktop MS Store build) for a zip-uploaded stdio plugin, so the failure appears transport-agnostic. This report likely explains #85623.

What Should Happen?

--plugin-dir should load the plugin's MCP servers the same way normal plugin resolution does — or, if it is intentionally skills/commands-only, that should be documented and the desktop app should use a loading path that includes MCP servers. A plugin's tools should be available in desktop-app sessions exactly as they are in terminal sessions.

Error Messages/Logs

No error is surfaced anywhere - the MCP server silently never starts.

Desktop app main.log shows the plugin being passed to the SDK:
[CCD] Passing 3 plugin(s) to SDK (skills: 1, remote: 0, local: 2)

Confusingly, `claude mcp list` (run separately in a terminal) reports the plugin server healthy:
plugin:ado-mcp:ado: https://mcp.<internal-host>/ado/sse (SSE) - Connected

...while sessions launched with --plugin-dir have no mcp__plugin_ado-mcp_ado__* tools.

Steps to Reproduce

Setup: plugin installed at user scope from a directory marketplace. Its .mcp.json:

{ "mcpServers": { "ado": { "type": "sse", "url": "https://mcp.<internal-host>/ado/sse", "headers": { "X-ADO-PAT": "${user_config.ado_pat}" } } } }

userConfig.ado_pat is sensitive: true with its value present in ~/.claude/.credentials.json pluginSecrets. Plugin enabled in ~/.claude/settings.json enabledPlugins. No disabledMcpServers in any settings scope.

1. Baseline — normal resolution registers the plugin's MCP tools:

claude -p "List tool names containing 'ado', one per line; if none say NONE." --output-format text

Result: 44 mcp__plugin_ado-mcp_ado__* tool names.

1. Same binary, same machine, same prompt, plus --plugin-dir pointing at the plugin's own cache directory (which contains .claude-plugin/plugin.json, .mcp.json, skills/):

claude -p "List tool names containing 'ado', one per line; if none say NONE." --output-format text --plugin-dir "%USERPROFILE%\.claude\plugins\cache\tao-internal\ado-mcp\0.3.0"

Result: NONE. (Skills from the --plugin-dir copy DO load.)

1. Identical results with 2.1.221 (the desktop app's bundled runtime, invoked directly) and 2.1.228 (CLI).

1. Desktop-app impact: every session the app spawns carries --plugin-dir flags (command line in "What's Wrong"), so desktop Code and local Cowork sessions have no plugin MCP tools while the plugin's skill still triggers.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.228 (Claude Code) - also reproduced with 2.1.221 (the desktop app's bundled runtime at %APPDATA%\Claude\claude-code\2.1.221\claude.exe, invoked directly)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

• Related: #85623 reports the same symptom signature (plugin skill loads, MCP tools never do; desktop MS Store build) for a zip-uploaded stdio plugin, with no root cause identified - the --plugin-dir mechanism reproduced here likely explains it. #25664 independently documents the app forwarding --plugin-dir cache paths into spawned sessions (different failure: SSH remote hang).
• Desktop app: MSIX/Store build Claude_1.25927.0.0_x64 on Windows 11 Pro 10.0.26200. Its bundled runtime self-update is off ([CCD-autoupdate] Disabled: MSIX install).
• Ruled out before this repro: org-catalog/local duplication (the Plugin "X" exists in both remote and local. Using remote. case - the catalog copy was removed org-wide first), disabledMcpServers (absent in all settings scopes), stale sessions (full tray-quit + relaunch), runtime version (both 2.1.221 and 2.1.228 reproduce).
• Internal MCP hostname redacted; happy to provide full logs privately.