StepSecurity has added an inventory of Claude Code and Codex plugins installed on developer machines and another of plugins published or enabled by an organization’s GitHub repositories. For teams whose developers run coding agents against company source, the useful question is now two-sided: which extension is on a machine, and which repository put it within reach? The StepSecurity product announcement describes both views. StepSecurity is evaluating its own product here.
An agent plugin can bundle executable hooks and MCP servers alongside skills. That makes the publisher and actual file source worth checking before a plugin reaches a laptop with developer credentials. The Miasma, JetBrains and GhostAction incidents StepSecurity cites involved other developer-extension or repository mechanisms. This launch inventories agent plugins.
Plugins carry code into sessions
Anthropic’s Claude Code plugin documentation puts the privilege question plainly: “what the plugin runs, it runs as you.” An enabled plugin can add hooks that fire during the agent’s lifecycle and MCP servers that run alongside a session. A plugin’s manifest at .claude-plugin/plugin.json identifies it and describes components, but the publisher and homepage fields are supplied by the plugin author. They are labels to investigate, rather than proof of origin.
A Claude Code marketplace is a catalog containing .claude-plugin/marketplace.json with entries describing where to fetch plugins. Its listing and the plugin files can have different sources. A repository can also carry .claude/settings.json settings that enable a plugin for contributors. Each contributor still installs a project-scoped plugin on their own machine. The repository setting tells you where to remove enablement; the device inventory tells you where to disable an installed copy.
Two inventories expose different paths
StepSecurity says its Dev Machine Guard Agent Plugins view lists Claude Code and Codex installations by device, scope, version and enabled state. It shows the marketplace and the location the plugin’s files came from separately. A disabled installation stays on the list because it can be enabled again. Component counts and attribution on the Agent Skills and MCP Servers pages help trace a skill or tool server back to its plugin. The endpoint inventory requires Dev Machine Guard agent v1.17.0 or later.
StepSecurity says the endpoint scan reads agent records, configured marketplaces, manifests and component definitions at user and project scope. It does not execute plugins, hooks, scripts or the agents’ CLIs, and it makes no network requests. Definition hashes and metadata go to the inventory; skill bodies, credentials and complete settings files stay on the device. Use those results to locate installed components; review the code’s origin and behavior separately before allowing it into a session.
The GitHub Agent Plugins view finds .claude-plugin/plugin.json and .codex-plugin/plugin.json manifests in organization repositories, including plugin folders below the root. It shows the publishing repository, folder, branch and scanned commit next to the author and repository fields declared in the manifest. Its “Used by” list names repositories whose settings enable a plugin. If a manifest claims your platform team as publisher but the scanned repository and folder belong elsewhere, investigate the source before trusting that name. A repository publishing a plugin and a repository enabling one are different things; check both columns.
Trace installations to repository sources
Start with the GitHub Agent Plugins view for repositories distributing or enabling plugins, then open the Dev Machine Guard view to find the machines that actually have a plugin installed. Compare its marketplace, “Plugin files from” location, manifest author, version and enabled state with the publishing repository, folder and commit. Export the device inventory to CSV if you need to route owners across a fleet. The two views are most useful together when a manifest’s declared identity and the observed source diverge.
For a plugin your team cannot account for, remove its enabling entry from the affected repository’s .claude/settings.json through review, and disable its installation on affected developer machines. Anthropic documents disabling an installed Claude Code plugin with claude plugin disable; use the corresponding management workflow for the agent and installation in question. Recheck the repository’s “Used by” list and the device installation state after the changes. The expected result is that the repository no longer enables that plugin and the affected devices show it disabled or removed. A plugin left installed but disabled remains a future enablement decision, so keep its source and owner in the inventory review.