Plugin archives can carry their own fetch headers or a helper command instead of inheriting them.
What's wrong with this entry?
Marketplace catalog entries and plugin entries declared in settings files both accept headers and a headersHelper command, so an archive no longer has to inherit authentication from the enclosing marketplace. -y, --yes now also consents to the helper command used to fetch an archive, and on updates to a changed install command.
- An entry's own auth is bound to its URL and overlaid on the enclosing url-source marketplace's headers only when the archive shares that origin.
- One resolver now decides archive auth from the marketplace source, the trusted declaration and the settings-entry auth together.
headersHelpervalues are validated as printable ASCII and capped at a length the install consent pane can render.- A managed-policy refusal reports
entry_helper_disabled_by_policyorentry_helper_remote_policy_unconsented. - Trust telemetry gained
hasMarketplaceHeadersHelperandhasRepoHeadersHelpers; a new on-disk cache namespacepluginAssetCache, keyed by archive digest, sits alongside.
headersHelper must not be longer than the install consent UI can display, bound to this URL, one whose archive is fetched through a headersHelper command (required when stdin or stdout is not a TTY)
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.248
Separate failure code when a credential helper's token is rejected
Both mention header helper
-
v2.1.248
Credential-helper tokens suppress the MCP OAuth flow
Both mention header helper
-
v2.1.227
Bad HTTP header values are rejected before the request instead of crashing
Both mention header helper