Agent-plugin launch client violates Agent Plugins 1.0 loader containment and executes load-time side effects

agent-plugin-loader-conformance is a high severity check in the ai category, written in shell. Its source is templates/ai/agent-plugin/agent-plugin-loader-conformance.sh in cert-x-gen-templates.

What it checks

Installs one benign synthetic Agent Plugins 1.0 package into a private plugin root under a probe-controlled $HOME and opens it with the launch client, after a conformant control package has first established that the client implements the format at all. The package exercises four normative MUSTs at once - a $schema naming a loopback canary URL that a loader MUST NOT retrieve, a component under a reverse-domain namespace the client does not own that MUST be ignored without validation, a plugin-declared env block supplying the reserved name PLUGIN_ROOT that MUST NOT be honoured, and an autoStart MCP server that MUST NOT run without a consent step - each carrying its own nonce and its own canary. Any arm honoured proves the loader is not a containment boundary: a four-week-old cross-vendor package format with no signing, no permissions and no provenance means whoever publishes a package chooses what runs, what is fetched, and what the child process’s environment says, on the machine of whoever installs it.

There is a playbook for this check

Agent-plugin loader containment & load-time side effects sets out the use case, the probe flow, the oracle, and the fixture that proves it in both directions.

Header

Field	Value
Id	agent-plugin-loader-conformance
Severity	high
Language	shell
Category	ai
Author	CERT-X-GEN Security Team
Template version	not recorded
Confidence	88
CVSS	not recorded
Weakness	CWE-829
Tags	ai, agent-plugin, plugin-loader, cli, conformance, load-time-execution, namespace-confusion, env-injection, consent, supply-chain, cwe-829, cwe-94, cwe-1188, cwe-668
Target kind	cli
Oracle	property

Conventions of the repository, not fields the engine reads

@target_kinds and @oracles are documented in the templates repository’s contribution guide, and cxg’s annotation parser does not carry them into a template’s metadata. Nothing at scan time selects on them. The annotation header schema is every field the parser does read.

References

Declared in the header. cxg parses @references and then discards it, and nothing at scan time reads it, so this is the only place the links a template cites are surfaced.

• https://docs.claude.com/en/docs/claude-code/plugins

Run it

To see what the copy on your machine says about itself, and to confirm it is installed at all:

cxg template info agent-plugin-loader-conformance

The id it prints is the one to pass anywhere a template is selected. See cxg template for the rest of the subcommand, Scan a target for running a scan, and A match is not a finding for how to read what comes back.

Related

• Template catalog is the whole corpus.
• ai is the rest of this category.
• Templates by weakness class groups checks by the defect they look for.
• Contribute a template is the route from a check you needed and could not find to a merged one.