Desktop app: "Failed to update marketplace" for plugins installed via remote/account-scoped install path
Description
Refreshing a plugin in the Desktop app that was installed through the remote/account-scoped install path fails with "Failed to update marketplace". The Desktop app shells out to the CLI to perform the update, but the CLI has no local record of the marketplace, so the command fails.
Steps to reproduce
- Install a plugin via the Desktop app using the remote/account-scoped install flow (app logs show
installPlugin: attempting remote API install for plugin <plugin>@<marketplace>, e.g.handsonai@handsonai-plugins). - In the Desktop app, trigger a refresh/update for that plugin's marketplace.
- Observe the error: "Failed to update marketplace".
This can also be reproduced directly on the CLI:
$ claude plugin marketplace update handsonai-plugins
Marketplace 'handsonai-plugins' not found. Available marketplaces: claude-plugins-official
claude plugin marketplace list confirms the marketplace is genuinely absent from local config — only claude-plugins-official is registered:
$ claude plugin marketplace list
Configured marketplaces:
❯ claude-plugins-official
Source: Git (https://github.com/anthropics/claude-plugins-official.git)
Root cause (suspected)
The Desktop app's remote/account-scoped plugin install path installs the plugin but does not register the corresponding marketplace in the CLI's local marketplace registry (~/.claude/plugins/known_marketplaces.json / ~/.claude/plugins/marketplaces/). Since the app's refresh action delegates to claude plugin marketplace update <name>, and the CLI only knows about marketplaces it has locally registered, the update call fails for any marketplace/plugin installed exclusively through the remote install path.
Expected behavior
Either:
- The remote/account-scoped install path should also register the marketplace locally so CLI-backed operations (like update) work, or
- The Desktop app's refresh/update action should use a mechanism consistent with how the plugin was installed, rather than always shelling out to the local CLI marketplace commands.
Environment
- Claude Code CLI version: 2.1.231
- OS: macOS (Darwin 24.6.0)
- Plugin:
handsonai@handsonai-plugins
3 Comments
Follow-up: workaround + additional root-cause detail
Worked around this by manually registering the marketplace with the CLI:
This surfaced a second contributing factor: the marketplace registered under the name
handsonai(taken from the marketplace manifest), nothandsonai-plugins(the repo name) — which is the name the Desktop app/original error used (Marketplace 'handsonai-plugins' not found).So beyond the "remote-install path never registers the marketplace locally" issue, there's a name mismatch: the Desktop app appears to assume the marketplace name equals the repo/slug name, when it actually comes from the marketplace's own manifest and can differ. Even if the remote-install path is fixed to register the marketplace locally, it would need to register it under the manifest-declared name (
handsonai), not the repo name (handsonai-plugins), or the app's lookups will still fail to match.Hitting this same error on a different path than the original report.
@KomalPY's repro is the remote/account-scoped install flow. Mine is an admin-configured marketplace delivered through
allowedPluginMarketplaceson Claude Desktop 3P. In my case no plugin ever gets installed, so I don't think the remote install path is involved at all, but the failure looks identical. I'm not sure if that means the gap is in the configured-marketplace syncer generally rather than the remote install path specifically. Might be worth widening the title.Environment
Claude Desktop (3P) 1.34493.1
Bundled Claude Code CLI 2.1.237
macOS 26.6.2 (Darwin 25.6.0)
Marketplace config comes from our bootstrap server response, not MDM:
The marketplace repo is internal and uses only relative
sourcepaths, so there are no external plugin sources involved. The manifest validates fine.Symptoms
What I found
There are two registries and only one of them is getting written.
The 3P host side syncer fetches everything fine and writes its own registry at
cowork_plugins/known_marketplaces.json. That file was correct, right repo, freshlastUpdated, and the fetched tree on disk was complete and current.The CLI registry was missing entirely:
The Code tab and the Update button both go through the CLI, so both see nothing. The two halves disagree inside the same second:
Same conclusion as the original report (the CLI has no local record so the shelled out command fails), just reached without ever installing a plugin.
Possibly a second issue
The 3P syncer writes the marketplace as a plain file copy, not a git working copy:
So even if the name were registered,
claude plugin marketplace update <name>has no working copy to pull into. Registering the marketplace and letting the CLI clone its own copy gets around this. I only mention it because if the fix is "register the existing synced directory" then I think this will bite.Workaround (confirmed working)
Registering the marketplace with the CLI by hand fixes both symptoms:
After a relaunch:
Code tab populates and Update succeeds.
This isn't great for the admin configured case though. The whole point of
allowedPluginMarketplacesis that users don't have to do anything, and this needs every user to run a CLI command against a path with a version number in it that changes every app update. It also duplicates a registration the admin config already declares.Suggested fix
Of the two options in the original report, the first one seems like it generalizes better. Whatever registers a marketplace should write both registries. In our case that would mean
custom-3p:configured-marketplacesalso writing to~/.claude/plugins/known_marketplaces.jsonafter a successful fetch, so CLI backed operations work for admin provisioned marketplaces without the user doing anything.Happy to supply full logs or test a build if that helps.
Additional data point that may narrow this, because it appears to rule out the stated
mechanism for at least one class of this failure.
The description here attributes the error to Desktop shelling out to the CLI, which then has
no local record of the marketplace. We reproduced the same failure in claude.ai in a
browser, which does not shell out to a local CLI and has no access to
~/.claudeat all.Same marketplace, same behaviour.
Three independent clients — Claude Code CLI, Claude Desktop, and claude.ai web — all refuse
to add or update the same private marketplace, reporting either "Failed to update
marketplace" or "marketplace already added".
What we verified before concluding it is server-side:
claudeGitHub App is installed on the organization withrepository_selection: all; org third-party access is approved; both users are org membersand the second has
write; the pre-transfer URL still redirects correctly via the API.git fetch+git merge --ff-onlyagainst thesame remote with the user's own credentials succeeds and fast-forwards cleanly.
known_marketplaces.json,settings.json(
extraKnownMarketplaces),enabledPlugins, or~/.claude/plugins/marketplaces/referenceit. A grep for any marketplace name across Desktop's
Local Storage,IndexedDBandPreferencesreturns nothing.With no local record on the machine and a browser client failing identically, the remaining
explanation is an account-scoped registration held server-side that no client surface can
inspect or clear. The practical consequence is that the usual remedy — remove and re-add —
is unavailable: removal appears to succeed, and the subsequent add still reports "already
added".
Preceding symptom, in case it is the same root cause: the marketplace was registered with
autoUpdate: trueand silently stopped updating, leaving the local clone 5 commits behindand the Desktop copy 5 releases behind, with no error surfaced until an update was attempted
by hand. That half closely matches #83422.
Environment: Claude Code 2.1.247, Claude Desktop on macOS 26.4.1, plus claude.ai in a
browser. Personal plan. Private repo in a GitHub organization.