Claude Code Adds Owner-Wildcard Marketplace Controls, Letting One Rule Allow or Block an Entire GitHub Org

Does owner-wildcard matching differ substantively in security terms from listing each repository name individually?

What this feature changes is maintenance cost, not the security strength of any single rule. Listing repositories individually is actually more precise as a rule — each rule maps to one specific, explicit repository. Owner wildcards instead substitute the trust judgment for an individual repository with a larger unit of trust, the organization: if content in any one repository under that organization ever has a problem (compromised, or a contributor's permissions abused), a wildcard rule automatically covers that problem within the already-allowed scope, with nothing extra to catch it.

This means using an owner wildcard effectively shifts the trust level up from "repository" to "organization" — whether the security is adequate depends on how rigorous that organization's own access control and governance actually are. This is also why the feature fits best for situations genuinely controllable within your own organization; choosing to allow an external third-party organization via wildcard effectively coarsens the grain of your risk judgment, and needs a correspondingly solid basis of trust in that entire organization to be reasonable.

Why was SHA-256 integrity verification added alongside this, and is it part of the same context as owner wildcards?

While these two features solve problems at different layers, they do fit together under one umbrella: owner wildcards address which sources can be trusted, while SHA-256 verification addresses whether the content actually downloaded, even from a trusted source, was tampered with in transit. Together, these form a reasonably complete supply-chain trust mechanism — trusting an organization alone doesn't guarantee every file it publishes stays untampered during transit (a man-in-the-middle attack, or the distribution server itself being compromised); conversely, verifying a file's hash alone doesn't help if you downloaded it from an untrusted source in the first place — all you've verified is that this is the exact file the attacker meant to give you.

Bundling these two features into the same round of updates reflects, to some degree, Anthropic strengthening supply-chain security from both angles — source governance and content integrity — as the Plugin ecosystem scales up. This lines up directionally with the recent string of moves around third-party Skill upload scanning and the GitHub-repo Skill trust boundary.

If my organization has a strictKnownMarketplaces allowlist configured, and a repository previously allowed later gets compromised, does this rule automatically Block it?

No. strictKnownMarketplaces checks whether a given marketplace source is in the allowlist — a source-level static comparison, not continuous content-level monitoring. In other words, as long as a repository's location (say, acme-corp/approved-plugins) doesn't change, even if its content is later tampered with by an attacker, the rule will still judge it as "an allowed source" and let it through — because the rule checks "is this an address I recognize," not "is whatever's currently at this address still safe."

This is exactly the gap SHA-256 integrity verification fills: if an individual Plugin entry in a marketplace has a sha256 field set, then even if the source itself is trusted, an install still gets refused if the actual downloaded file's hash doesn't match what was pre-configured. But this only covers plugins distributed through an archive source; plugins distributed through git-based sources (github, url, git-subdir) currently have no equivalent hash-checking mechanism. The closer protection there is pinning a specific commit via the sha field, preventing content from being swapped to a different version without your knowledge — but that still assumes the commit you originally pinned was clean to begin with.

If I need to design a Plugin marketplace governance policy for my organization, how should these two features actually work together?

A more robust approach is to split them across different layers: use owner wildcards for coarse-grained, organization-scope trust decisions — allowing your company's own GitHub organization (your-org/*), blocking a known-problematic external organization. For individual, especially critical plugins (particularly ones with elevated permissions or widely installed), additionally require the publisher to provide a SHA-256 hash, or require distribution through a git source with a specific commit sha pinned, giving content integrity a layer of protection independent of whether the source itself is trusted.

One easily overlooked practical detail: owner-wildcard matching is exact — acme-corp/* only covers repositories under that specific owner, and won't accidentally cover a similarly named repository under a different owner. Also, strictKnownMarketplaces is checked on marketplace add and on every install, update, refresh, and auto-update — if a marketplace was added before the policy was configured and its source no longer matches the allowlist, the rule, once in effect, straightforwardly refuses further installs and updates from that source. This means it's worth proactively auditing your currently installed marketplace list after any policy change, to confirm no necessary source got accidentally blocked.