Plugin marketplaces hardened — a second git host, pinned archives, blocked lists

Why you'd careThe problem it solves

Authoring a skill is a settled problem. You write a SKILL.md, you iterate on the description until the model picks it up when it should, and the format has been stable long enough that a page about it does not need a date on it. Getting that skill onto forty machines, knowing which version each of them has, and being able to say afterwards where it came from is not settled at all.

Nothing in the skill format helps with any of that, and the vendor-neutral packaging standard released this same month is explicit that it will not either — its guide for client implementers says it “does not prescribe” “installation sources, registries, or marketplaces”, “enablement, update, or cache user experience” or “permission prompts, trust policy, or sandboxing”. So each client builds this layer itself, and what lands in a release window is a fair reading of which problems turned out to be real. In this window the answer was: a second git host, a git-free install path, blunt enterprise controls, and several fixes to things that were quietly wrong.

ConceptWhat it is

Four separate mechanisms sit between a skill you wrote and a skill a colleague is running, and the changes in this window touch each of them. Keeping them apart is most of the work of reasoning about the surface.

The source is where a plugin's bytes come from. Until this window that effectively meant cloning a git repository. It now also means a zip fetched over HTTPS, or a local command that prints a directory.

The marketplace is the catalogue that lists plugins — a repository with a catalogue file, registered on the machine under a name. Registration is state on disk, which is why a concurrency bug in that state is a distribution bug.

The managed policy is what an administrator sets centrally: which marketplaces are permitted, which are refused. Its correctness is entirely a question of whether the thing it checks is the thing that later gets dialled.

The sync path is separate from all three: skills that arrive on a machine from claude.ai rather than from a marketplace. It got the sharpest security work in the window, and the fact that it needed it is the argument for keeping it mentally separate from the plugin route rather than lumping the two together as “skills from elsewhere”.

How it worksThe mechanics

The changes, by version, with what each one actually buys:

Three settings and policy details land alongside those. additionalMarketplaces and allowedMarketplaces are now accepted as friendlier aliases for extraKnownMarketplaces and strictKnownMarketplaces — a naming fix, and one worth knowing about so a settings file written by a colleague does not read as invalid. A url-typed blockedMarketplaces entry for a bare repository URL keeps blocking that URL when the CLI classifies it as a git clone; a block that stops applying because the input was reclassified is not a block. And strictKnownMarketplaces allowlists no longer accept SCP-style git marketplace sources whose host differs from the one git would actually connect to — an allowlist checking a name that was not the name being dialled.

Three reliability fixes are, in effect, the same lesson from three directions. Plugin install records were being silently corrupted when the same plugin is installed in multiple projects. A startup race could silently unregister a plugin marketplace, through concurrent writes to known_marketplaces.json. And /plugin install plugin@marketplace now refreshes the marketplace first, so newly published plugins install without a manual marketplace update — the failure it removes looked exactly like a publish that had not worked.

The item with the sharpest edge is the one nobody asked for. Skills synced from claude.ai were hardened so they “no longer shadow local commands or MCP prompts, their descriptions are sanitized and labeled, and on your machine their bodies don't run ! commands or expand @ files”. Read that backwards and it is a list of things a synced skill could previously do to a local machine, and a good argument for treating any sync path as a distribution channel with its own trust question rather than as a convenience.

At a glanceSee it

Three ways a plugin can arrive, one policy gate that decides whether it may, and the check that runs on what lands.

Where it runsSurfaces and availability

Read the window as a whole and the shape is consistent: the format of a skill did not move at all, and everything around getting one from an author to a machine did. That is the layer where the real questions live now — which host, which bytes, whose policy, and what a package is allowed to do after it lands. If you maintain skills for other people, this is the part of the surface to re-read each release rather than the SKILL.md documentation, which has been stable for a long time.

ExampleIn the real world

An organisation runs its internal tooling on a self-managed GitLab instance and its plugin marketplace on GitHub, purely because the marketplace could not be anywhere else. Two of the paths are now open: from v2.1.232 a bare gitlab.com repository URL, including nested subgroups, clones the way a github.com one does, and a failed clone names the actual git host rather than a generic hint — which is the difference between one debugging session and none.

A different team has a stricter constraint: nothing on developer machines may clone from the public internet. Their answer is the archive source. The plugin is published as a zip on an internal HTTPS host and installed with its SHA-256 pinned, so what a machine installs is byte-identical to what was reviewed, and no git or npm is in the path at all.

Central policy is one line rather than a list. strictKnownMarketplaces carries "acme-eng/*", which admits every marketplace repository under the organisation, including the ones created next quarter. A vendor repository that must never be installed from goes into blockedMarketplaces as a URL, and it keeps blocking that URL even when the CLI classifies the source as a git clone.

The thing that actually bit them last month was none of the above. Two projects had the same plugin installed, and the install records were being silently corrupted — a state bug, not a policy one, fixed in v2.1.224. It is the kind of failure that reads as user error for weeks, which is why the release notes on this layer are worth reading rather than skimming.

Not thisWhat it is often confused with

• Not a package registrythere is no dependency resolver and no central index. A marketplace is a repository with a catalogue file; the sources added in this window change where bytes come from, not what resolves them.
• Not provenancea SHA-256 pin proves the bytes match the ones you pinned. It says nothing about who produced them. Integrity and authenticity are different properties and only the first one is on offer.
• Not a sandboxan allowlist decides whether a plugin may be installed, not what it may do afterwards. The synced-skills hardening is the reminder that those are separate questions with separate answers.
• Not the cross-vendor packaging standardthat specification deliberately leaves installation, registries, permissions and updates to each client. This page is one client's answer to the layer it left open.
• Not a review stepclaude plugin validate checks that SKILL.md frontmatter parses. It is a syntax check on a directory, not a judgement about what the instructions inside say.
• Not the same as skills synced from claude.aia different path with its own trust story, hardened separately in this window.

LimitsWhen not to reach for it

• One repository, one team.Commit the skill under .claude/skills. Marketplace mechanics are a cost you pay per edit and they buy nothing until something has to leave the repository.
• You need signed provenance.Hash pinning is integrity, not authorship. If the requirement is “prove this came from the platform team”, it is unmet by everything on this page and has to be met by your own signing and review process.
• You are relying on a version older than the change you need.Every item here is dated to a release. An allowlist written against a build that predates the SCP-style host fix is not the allowlist you think you have.
• You expect a git or archive source to pick up changes mid-session.The command source is the one documented as re-resolved each session and applied without a restart. Do not generalise that to the others.
• The behaviour must be guaranteed, not offered.Distribution puts a skill on a machine; it does not make the model use it. If something must happen every time, that is a hook or a CI check.

RelatedGo deeper