Agent mode serves a stale per-session plugin snapshot after a plugin update (removed skills remain listed/invocable)

Summary

In Claude Desktop agent mode, each session extracts installed plugins into a private
per-session working copy at
…/local-agent-mode-sessions/<sessionGUID>/<subGUID>/rpm/plugin_<hash>/ once at session
start, and pins that snapshot for the whole session lifetime. If a plugin is updated while
the app is still running, the session keeps loading the pre-update snapshot — even though
~/.claude/plugins/installed_plugins.json and the plugin cache are already on the new version.
Because the model's available-skills list is built from that stale snapshot, skills that were
removed or renamed in the update remain listed and remain invocable, and updated skill code
does not take effect.

Environment

• Claude Desktop (MSIX), version 1.18286.0.0 — package family Claude_pzs8sxrjxfjjc
• Windows 11
• User-scope marketplace plugin installed via ~/.claude/plugins

Steps to reproduce

1. In agent mode, start a session. The app extracts plugins to

…/local-agent-mode-sessions/<guid>/<guid>/rpm/plugin_<hash>/.

1. Keep that app run open, and update an installed marketplace plugin to a newer version

(so installed_plugins.json and ~/.claude/plugins/cache/<marketplace>/<plugin>/<newver>/
are updated).

1. Keep using the same session — including starting a new conversation in the same app run.

Actual behavior

The running session keeps loading the old plugin version from its per-session rpm/ snapshot:

• installed_plugins.json → plugin 0.7.1 (installPath …/cache/…/0.7.1)
• Plugin cache contains only 0.7.1
• But the live …/rpm/plugin_<hash>/.claude-plugin/plugin.json → 0.6.7
• Timeline confirms it's a startup snapshot: rpm/ extraction mtime 20:26 vs cache/install

update 21:00 (the snapshot predates the update by ~34 min)

• A skill removed in 0.7.1 still appeared in the model's skill list and a subagent

invoked it during the session. No warning that the running version ≠ installed version.

Concrete instance observed: public sap-dev marketplace (github.com/sapdev-ai/sap-dev),
sap-dev-core 0.6.7 → 0.7.1. In 0.7.1 the skill sap-gui-object-details was merged/renamed
into sap-gui-inspect; the running session still listed and ran sap-gui-object-details.

Expected behavior

At minimum, a new conversation within the same app run should re-materialize plugins from
the updated cache. Ideally the session detects that installed_plugins.json changed underneath it
and refreshes (or prompts "plugins updated — reload"). Removed/renamed skills should not remain
invocable after an update. If per-session pinning is intentional (for reproducibility), the
running-vs-installed version mismatch should be surfaced so it is diagnosable.

Impact

• Plugin developers iterating on versions: edits silently don't take effect until a full app

relaunch — easily misdiagnosed as "my update didn't apply."

• Correctness: agents can invoke removed/renamed skills, or run old code that an update was

specifically meant to retire (e.g. a skill whose known bug is fixed in the newer version).

Workaround

Fully quit Claude Desktop, delete the per-session rpm/ extraction(s) under
…/local-agent-mode-sessions/*/*/rpm/, then relaunch to force a fresh extraction. On MSIX the
real path is
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\local-agent-mode-sessions\….

Notes

• Only the per-session rpm/ snapshot is stale — the marketplace checkout, plugin cache, and

installed_plugins.json are all correct.

• Minor/secondary: because the app is MSIX-packaged, its data under %APPDATA%\Claude\… is

virtualized to …\Packages\<PFN>\LocalCache\Roaming\Claude\…. Tooling spawned by the app (inside
the container) sees %APPDATA%\Claude, but the user's Explorer (outside) does not — only relevant
if any user-facing guidance points at %APPDATA%\Claude.