Desktop app: per-workspace plugin store syncs on schedule but never downloads (silent, every indicator green)

Bug report — Claude desktop app: per-workspace plugin store syncs on schedule but never downloads

Product: Claude desktop app for Windows (MSIX build 1.37937.0.0), plugin sync from a private plugin marketplace
Observed: 26 and 28 August 2026, one Windows 11 machine, multiple accounts/workspaces
Severity: silent — every user-visible indicator reports healthy while the client serves stale content indefinitely

Summary

A workspace's plugin store under local-agent-mode-sessions\<account>\<org>\rpm\ reports successful syncs on its normal timer while downloading nothing, indefinitely, from a server that is serving newer content.

Every indicator available to the user is green. The marketplace entry reports auto-sync on. The store's manifest.json lastUpdated stamp advances on schedule. The claude.ai Plugins page shows the current version and skill count. Only the plugin folders stand still. Sessions on that workspace silently load plugin content weeks out of date, and nothing anywhere reports a fault.

Reproduction / evidence

26 August 2026. A workspace store held a plugin at version 1.69.0 while the marketplace source carried 1.106.1 — 37 minor versions, three days stale.

• The server record was verified current, not stale: the claude.ai Plugins page showed the plugin last updated that morning with 25 skills, matching the marketplace source exactly.
• The app process had started at 10:15:50 that morning, two hours after the newer version was published, so a launch sync had already run against current server content and taken nothing.
• Two further syncs were observed live, at 10:35 and 10:55. Each advanced manifest.json lastUpdated; neither moved any plugin folder.
• main.log on the machine stops on 21 August, five days earlier, so the client offered no diagnostic trail for any of it.

Workaround, and its failure. Toggling one plugin off and on in claude.ai Settings → Plugins fired an "installed and ready to use" event, and at the next sync tick the entire store re-downloaded — every plugin to current, not only the toggled one. That looked like a fix.

28 August 2026, same machine, same store. The store's newest plugin folder is still stamped 26/08 11:15 — the exact minute of that toggle — with a sync stamp of 28/08 21:15. Across two days of syncing on schedule it has taken nothing further. It never received a version published one hour after the toggle. The toggle is a one-shot unstick; the store re-froze immediately and stayed frozen.

The fault is per-store, not machine-wide. On the same machine over the same two days, three other workspaces' stores took content normally, reaching versions published that day. Two other stores are frozen much further back (one at a version from 22 August, another from 26 August). So the sync path itself works; particular stores stop consuming what it delivers, and once a store is in that state it does not appear to recover on its own.

Related, possibly a separate issue. On the same machine, Claude Code's own plugin pins drifted eight minor versions behind the marketplace over the same two days with auto-update reported ON. Only the documented manual update run (claude plugin marketplace update <name>, then claude plugin update <plugin>@<marketplace> per plugin) moved them.

Impact

The affected surface is where people actually work: desktop-hosted and Cowork sessions load from this store, not from the Claude Code pins. A user working from a stale store has no way to know, and the effect is invisible in the output — the plugin simply behaves like its older version. In our case the session diagnosing the problem was itself loaded from the frozen store, so the copy of the tool it was running was two versions behind the copy it was editing.

What would help

1. A user-visible content clock. The store already records a sync stamp; it does not surface when content last arrived. Those two values diverge precisely in this fault, and the gap between them is the entire signal. We ended up printing both side by side in our own checker because the sync stamp alone is actively misleading.
2. A failure mode that is not silent. A sync that computes an empty delta against a server holding newer content should log something the user can reach. With main.log stopping five days earlier, no trace existed at all.
3. A supported way to force a full re-sync of one store — given the toggle is a one-shot, and remove-and-re-add costs the workspace its plugins in between (and, as we found, sits one mis-click away from the toggle in the same dialog).
4. Confirmation of the sync timer's scope. We observed that the timer appears to run only for the workspace the app is currently open in; a second workspace's store on the same account sat unsynced for a day and did not move during a watched half hour. If that is by design it is worth documenting, because it changes what advice is correct for a user with more than one workspace.

Environment

• Windows 11 Pro 26200, Claude desktop app MSIX build 1.37937.0.0
• Claude Code CLI 2.1.246 (2.1.241 at first observation)
• Plugins served from a private GitHub-backed marketplace, auto-sync enabled throughout
• Happy to supply account and workspace identifiers, and the store timestamps, through a private support channel — they are omitted here deliberately.