[BUG] Account-enabled plugins auto-start a third-party MCP server on other devices with no local confirmation

• [x] I searched existing issues and didn't find a duplicate
• [x] This is a single bug report (not multiple issues combined)
• [x] I'm using the latest version of Claude Code

What's Wrong?

When a plugin becomes enabled at the account level, Claude Desktop on a separate, already-running machine downloads it and auto-starts its MCP server on the next background sync, with no local confirmation and no notification. The first visible sign on that machine was an unsolicited browser tab.

In my case nine plugins went from 0 to 9 account-enabled while the app sat idle overnight. One of them, desktop-commander, launches npx -y @wonderwhy-er/desktop-commander@latest and registers 26 tools covering terminal execution, process management, and filesystem read/write. That process started unattended and then opened a vendor welcome page in my default browser.

Two properties make this worse than a normal sync:

1. The launch command resolves @latest at every start, so the executed code is whatever was published most recently — it is not covered by the marketplace commit pin. This is already reported as anthropics/claude-plugins-official#5749, and the upstream pin PR (wonderwhy-er/DesktopCommanderMCP#657) has been open since August 25.
2. Nothing on the receiving machine asked. There is no prompt, no toast, and no entry in the UI indicating that a new local process with shell access had been started.

To be precise about scope: I am not asserting how the account-level state changed. What this report covers is the receiving device's behavior — an account flag flipping elsewhere should not silently result in a new shell-capable process on a different machine.

What Should Happen?

Enabling a plugin at the account level should not, by itself, start a third-party MCP server on every signed-in device. Expected behavior, roughly in priority order:

1. Confirm locally before first launch of a plugin-provided MCP server that requests shell or filesystem access — at minimum a one-time "X was enabled on your account. Start it on this device?" prompt.
2. Never open a browser tab as a side effect of an unattended background sync.
3. Surface a visible record in Settings → Plugins of when each plugin was enabled and which device enabled it, so an unexpected arrival can be traced without reading main.log.

Error Messages/Logs

From ~/Library/Logs/Claude/main.log, timestamps local, identifiers redacted:

03:16:24 [info] [PluginsFetcher] fetchAccountEnabledPlugins: 0 plugins
...
04:36:23 [info] [RemotePluginManager] Periodic tick upgrading to full pass (staleness 3600000ms, elapsed 4799917ms)
04:36:23 [info] [RemotePluginManager] Starting remote plugins sync
04:36:24 [info] [PluginsFetcher] fetchAutoInstalledPlugins: 0 plugins
04:36:24 [info] [RemotePluginManager] Delta: 0 to download, 0 to remove
04:36:24 [info] [PluginsFetcher] fetchAccountEnabledPlugins: 9 plugins
04:36:24 [info] [PluginsFetcher] fetchPluginEnabledState: 9 overrides
04:36:26 [info] [RemotePluginManager] Downloaded 9 account-enabled plugin(s)
04:36:26 [info] [RemotePluginManager] Sync complete: 9 downloaded, 0 removed, 0 orphans cleaned
...
05:16:27 [info] [LocalMcpServerManager] Connecting to plugin:desktop-commander:desktop-commander
05:16:27 [info] [LocalMcpServerManager] Using MCP server command: /opt/homebrew/bin/npx
05:16:43 [info] [LocalMcpServerManager] plugin:desktop-commander:desktop-commander negotiated protocol version: 2025-11-25
05:16:43 [info] [LocalMcpServerManager] Connected to plugin:desktop-commander:desktop-commander (26 tools)
05:16:49 [info] [localMcpBridge] announcing plugin:desktop-commander:desktop-commander: 26 tool(s)

Note Delta: 0 to download, 0 to remove immediately before Downloaded 9 account-enabled plugin(s) — the account-enabled path appears to bypass the delta/auto-install path that logs a download plan.

The resulting process tree, still running 45 minutes later:

/Applications/Claude.app/Contents/Helpers/disclaimer --pgroup -- /opt/homebrew/bin/npx -y @wonderwhy-er/desktop-commander@...
npm exec @wonderwhy-er/desktop-commander@latest
node ~/.npm/_npx/<hash>/node_modules/.bin/desktop-commander

Browser history recorded exactly one visit, at 05:16:43, matching the MCP connect to the second:

https://desktopcommander.app/welcome/?utm_source=local-agent-mode-plugin%3Adesktop-commander%3Adesktop-commander

Steps to Reproduce

1. Sign in to Claude Desktop on machine A and leave it running and idle.
2. Enable a plugin whose plugin.json declares an mcpServers entry — desktop-commander from the knowledge-work-plugins marketplace is the case here — so that it becomes account-enabled.
3. Do not touch machine A. Do not open Settings on machine A.
4. Wait for the periodic full-pass sync on machine A (observed at an 80-minute cadence; quick syncs every 20 minutes skip user-plugin cleanup).
5. Observed: machine A logs Downloaded N account-enabled plugin(s), then on a following tick starts the plugin's MCP server via npx, registers its tools, and the plugin opens a page in the default browser. No prompt appears at any point.
6. Expected: machine A does not start a third-party shell-capable process, or asks first.

Claude Model

Not applicable — this is client sync and MCP lifecycle behavior, not model output.

Is this a regression?

Don't know. I have no prior instance of an account-level plugin enable reaching this machine, so I cannot name a last-working version.

Environment

- Claude Code Version: 2.1.280
- Claude Desktop Version: 2.7032.0
- Platform: Max subscription
- Operating System: macOS 26.6.2 (25G83), Mac Studio M2 Ultra
- VS Code: 1.138.0
- VS Code extension: anthropic.claude-code@2.1.219
- Terminal/Shell: VS Code integrated, zsh

Additional Information

Config context from the same machine, in case it narrows the path:

"userPluginMarketplacesEnabled": true
"userPluginUploadsEnabled": true
"extensionsEnabled": true
"localExtensionInstallAllowed": true
"deploymentMode": "1p"

Settings → Plugins exposes only Remove per plugin, with no enable/disable toggle and no "added on" metadata, so the UI offers no way to audit when a plugin arrived or to keep it installed while preventing it from launching. The audit trail exists only in main.log.

Removing the plugin from the account cleared the entry immediately, but the already-running node process persisted until it was killed manually — worth confirming whether removal is meant to tear down a live MCP server or only prevent future launches.