[BUG] Desktop plugin stores desync: sessions load stale account-registry copies that shadow current CLI installs; settings Update checks the wrong store and Uninstall deletes from both

Summary

Claude Desktop on Windows maintains two independent plugin stores but presents them as one, producing three concrete defects observed and verified on 2026-08-03:

1. Desktop sessions load a stale account-registry plugin copy that silently shadows the current CLI install of the same plugin.
2. The Desktop plugin settings panel reports "already at latest" because its Update button checks only the CLI store — not the registry copy that sessions actually load.
3. The same panel's Uninstall action is destructive across both stores: removing a registry-installed plugin also deleted unrelated CLI-store installs.

Environment

• Claude Code CLI: 2.1.220
• Claude Desktop (Windows), current as of 2026-08-03
• OS: Windows 10 Pro 10.0.19045

Background: the two stores

• CLI store: ~/.claude/plugins/cache/<marketplace>/<plugin>/<version>/, maintained by claude plugin update <plugin>@<marketplace> and marketplace autoUpdate.
• Account registry: server-side entities (plugin_01… / marketplace_01… IDs) recorded per-plugin in %APPDATA%\Claude\local-agent-mode-sessions\<id>\<id>\rpm\manifest.json with an updatedAt timestamp, materialized to rpm\plugin_*\ payload directories.

Desktop sessions load the union of both stores, and when a plugin exists in both, the registry copy wins.

Evidence

A third-party plugin (webworks-agent-skills) was installed twice: into the account registry via the Desktop UI on 2026-07-03 (then version 3.4.x) and into the CLI store, which was updated to 3.8.3 on 2026-08-03.

1. Shadowing (defect 1): A brand-new Desktop session created after the CLI update materialized the plugin at 3.4.3 (read from rpm\plugin_*\.claude-plugin\plugin.json inside the session). The rpm\manifest.json entry showed updatedAt: 2026-07-03T18:32:08Z, unchanged even though the manifest's own lastUpdated bumped at session start — i.e., the registry was re-checked and correctly found no registry-side update, while the CLI-side 3.8.3 was ignored. A second registry plugin (windworker, registered 2026-04-12) materialized a copy so old its plugin.json predates the version field, while the CLI store held 2.10.1.
2. Misleading "already at latest" (defect 2): In the Desktop plugin settings panel, hovering the Update button for the same plugin said it was already at the latest version, and "open containing folder" opened ~\.claude\plugins\cache\webworks-agent-skills\webworks-agent-skills\3.8.3 — the CLI store. So the panel's Update pipeline points at a store that Desktop sessions do not prefer, while sessions keep loading the stale registry copy. The only visible hint of staleness was the "last updated" date. Plugins that existed only in the CLI store (e.g. compound-engineering) showed current versions and fresh dates in the same panel — the panel displays a union of the two stores without indicating which store each entry (or the Update button) operates on.
3. Cross-store uninstall (defect 3): Uninstalling the registry-installed plugins through the Desktop UI (to eliminate the shadowing) also removed CLI-store installs of plugins that had never been registered in the account registry (compound-engineering@every-marketplace, markdown-plus-plus@markdown-plus-plus, feature-dev@claude-code-plugins, frontend-design@claude-code-plugins disappeared from claude plugin list and from enabledPlugins in ~/.claude/settings.json). Marketplace registrations survived; the plugins had to be reinstalled with claude plugin install.

Expected behavior

• A session should not silently prefer a months-old plugin copy over a newer install of the same plugin, or the UI should surface which copy a session will load.
• The settings panel's Update button should update (or at least report against) the store the sessions actually load from.
• Uninstall should act on the store the user is looking at, or clearly state it will remove the plugin from both stores.

Workaround that restored sanity

Removing all account-registry plugin installs (registry manifest now shows 0 plugins) makes Desktop sessions fall back to the CLI store for everything, after which CLI autoUpdate keeps all surfaces current. This works, but discovering it required reverse-engineering rpm\manifest.json, and executing it triggered defect 3.

Related

• #50644 (closed) requested unifying skills storage between Desktop and CLI — this report documents concrete defects the current split causes for plugins.
• Docs gap: https://code.claude.com/docs/en/desktop.md documents that Cowork sources plugins from the claude.ai account but does not state where local Desktop Code sessions load plugins from, nor the union/shadowing behavior.