claude plugin update <name> fails with "Plugin not found" for bare plugin names — only name@marketplace works (regression, ~Aug 5)

Reproduced on v2.1.233 (macOS).

Steps:

1. Create a marketplace directory with one plugin (myplugin, version 0.6.13) and add it: claude plugin marketplace add ./mymarket
2. claude plugin install myplugin@mymarket (succeeds at user scope; claude plugin list shows it enabled)
3. claude plugin update myplugin
4. claude plugin update myplugin@mymarket

Observed:

$ claude plugin update myplugin
Checking for updates for plugin "myplugin" at user scope…
✘ Failed to update plugin "myplugin": Plugin "myplugin" not found
$ echo $?
1
$ claude plugin update myplugin@mymarket
✔ myplugin is already at the latest version (0.6.13).
$ echo $?
0

Expected: the bare name resolves when it is unambiguous (installed from exactly one marketplace), the same way claude plugin enable myplugin, claude plugin disable myplugin, and claude plugin uninstall myplugin already do on the same setup.

Assessment: this looks like a genuine bug. The CLI reference (https://code.claude.com/docs/en/plugins-reference#plugin-update) documents the argument for plugin update as "Plugin name or plugin-name@marketplace-name", exactly like enable/disable, but update only ever accepts the scoped form and reports "not found" for a bare name even though plugin list shows the plugin installed. On the regression claim: I could not confirm one — the same failure reproduces on 2.1.207 and 2.1.227, so claude plugin update <bare-name> appears never to have worked from the command line, and whatever was pulling your releases before Aug 5 was most likely the built-in background marketplace auto-update rather than the hook. Either way, the fix is to resolve an unambiguous bare name to its installed name@marketplace entry (and, on ambiguity or a miss, have the error suggest the scoped form).

🤖 Generated with Claude Code

Reproduced on 2.1.233 (Linux) with a minimal setup: a local git marketplace containing a single plugin, installed at user scope.

$ claude plugin update myplugin
Checking for updates for plugin "myplugin" at user scope…
✘ Failed to update plugin "myplugin": Plugin "myplugin" not found   # exit 1

$ claude plugin update myplugin@mymarket
✔ myplugin is already at the latest version (0.1.0).                # exit 0

claude plugin list shows the plugin installed and enabled, and the official CLI reference documents the argument as "Plugin name or plugin-name@marketplace-name" — so the bare form should work when unambiguous, and this is a genuine bug rather than intended behavior.

One data point on the timeline: I also ran the same test against older builds (2.1.150, 2.1.205, 2.1.212, 2.1.216, 2.1.220) and the bare name fails identically on all of them — including versions current before your Aug 5 break window. So at least in this single-marketplace configuration, bare-name plugin update appears to have been broken for a long time rather than newly regressed; it's possible your auto-update hook stopped working around Aug 5 for a different reason, or that your earlier working setup differed in a way this minimal repro doesn't capture. If you can recall anything that changed around then (marketplace count, install scope, etc.) that would help pin down whether there are two issues here.

Either way: reproduced, and the failure mode is confirmed misleading — the error says "not found" for a plugin that plugin list shows as installed, instead of suggesting the scoped name@marketplace form.

🤖 Generated with Claude Code

Thanks for checking older builds — you're right, and I retract the regression claim on plugin update. Our own session logs show the hook's bare-name call failing since 2026-07-29 (≈2.1.220), so it never worked; the releases we received before Aug 5 were pulled by the background marketplace auto-update (the marketplace clone's reflog shows unattended pull origin HEAD every 1–3 days, with the plugin cache populated in the same second, no manual action).

That background auto-update stopped after 2026-08-05 15:22 UTC (last unattended pull). Since then no release was picked up in the background; only manual plugin update name@marketplace runs. So there may be a second issue here: our marketplace is a third-party git marketplace registered via user-scope extraKnownMarketplaces (self-hosted HTTPS git, single plugin, user scope, 4 marketplaces total), and today neither settings.json nor known_marketplaces.json carries an autoUpdate field — yet background updates were clearly running before Aug 5. Candidates I can see in the changelog for that window: 2.1.228 "marketplace entries now merge as whole entries" and 2.1.232 "startup race that could silently unregister a marketplace (known_marketplaces.json)". Nothing changed on our side (same marketplace count, same scope).

Happy to open a separate issue for the auto-update stop if that's cleaner.