Desktop app: "Failed to update marketplace" for plugins installed via remote/account-scoped install path

Status Open
Reported on v2.1.231
Maintainer reply None cached
Activity 3 comments · opened Aug 13, 2026

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

  1. 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).
  2. In the Desktop app, trigger a refresh/update for that plugin's marketplace.
  3. 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

View original on GitHub ↗

3 Comments

KomalPY · 17 days ago

Follow-up: workaround + additional root-cause detail

Worked around this by manually registering the marketplace with the CLI:

claude plugin marketplace add https://github.com/jamesgray-ai/handsonai-plugins
claude plugin marketplace update handsonai
claude plugin install handsonai@handsonai

This surfaced a second contributing factor: the marketplace registered under the name handsonai (taken from the marketplace manifest), not handsonai-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.

jxk590 · 6 days ago

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 allowedPluginMarketplaces on 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:

[{"source":"github","repo":"<org>/<marketplace-repo>","ref":"main",
  "installationPreference":"available","credentialKind":"userGit"}]

The marketplace repo is internal and uses only relative source paths, so there are no external plugin sources involved. The manifest validates fine.

Symptoms

  1. Settings > Plugins > Organization, Code tab shows "No plugins available." The marketplace chip renders but there are zero plugins under it.
  2. Update gives "Failed to update marketplace."
  3. The Cowork/Chat tab lists all the plugins correctly. Only the Code tab is empty.

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, fresh lastUpdated, and the fetched tree on disk was complete and current.

The CLI registry was missing entirely:

$ ls ~/.claude/plugins
ls: /Users/<me>/.claude/plugins: No such file or directory

$ ".../claude-code/2.1.237/claude.app/Contents/MacOS/claude" plugin marketplace list
No marketplaces configured

The Code tab and the Update button both go through the CLI, so both see nothing. The two halves disagree inside the same second:

[info] [custom-3p:configured-marketplaces] <org>/<repo> already current as '<marketplace>' (skipping clone)
[info] [NativeMarketplaceReader] Found 0 marketplace(s)
[info] [CCDMarketplacePluginManagerCLI] Refreshing marketplace: <marketplace>
[info] [HostCLIRunner] Command completed with exit code 1

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:

$ git -C ".../cowork_plugins/marketplaces/<marketplace>" rev-parse HEAD
fatal: not a git repository (or any of the parent directories): .git

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:

"$HOME/Library/Application Support/Claude-3p/claude-code/<ver>/claude.app/Contents/MacOS/claude" \
  plugin marketplace add <org>/<marketplace-repo>

After a relaunch:

[info] [HostCLIRunner] Command completed with exit code 0
[info] [CCDMarketplacePluginManagerCLI] Marketplace refreshed: <marketplace>
[info] [NativeMarketplaceReader] Found 1 marketplace(s)

Code tab populates and Update succeeds.

This isn't great for the admin configured case though. The whole point of allowedPluginMarketplaces is 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-marketplaces also writing to ~/.claude/plugins/known_marketplaces.json after 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.

adamjsimon · 7 hours ago

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 ~/.claude at 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:

  • GitHub is correct. The claude GitHub App is installed on the organization with

repository_selection: all; org third-party access is approved; both users are org members
and the second has write; the pre-transfer URL still redirects correctly via the API.

  • The repo is reachable from the machine. git fetch + git merge --ff-only against the

same remote with the user's own credentials succeeds and fast-forwards cleanly.

  • Local state is empty. After cleanup, none of known_marketplaces.json, settings.json

(extraKnownMarketplaces), enabledPlugins, or ~/.claude/plugins/marketplaces/ reference
it. A grep for any marketplace name across Desktop's Local Storage, IndexedDB and
Preferences returns 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: true and silently stopped updating, leaving the local clone 5 commits behind
and 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.