> For the complete documentation index, see [llms.txt](https://docs.stepsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stepsecurity.io/developer-machines/ide-and-ai-agents/agent-plugins.md). # Agent Plugins {% hint style="info" %} The Agent Plugins inventory requires Dev Machine Guard agent **v1.17.0 or later** {% endhint %} The **Agent Plugins** page provides an organization-wide inventory of the Claude Code and Codex plugins installed across developer machines: which plugins are present, which marketplace each came from, whether it is enabled, and what it brings with it. A plugin is a bundle. A single install can add skills, commands, MCP servers, subagents, hooks, and LSP servers to an AI agent at once, all of which run with the developer's own privileges. Plugins are usually installed from a marketplace, which can be a public catalog, a Git repository, a hosted URL, or a local directory, and some arrive without one, for example bundled with an account. This page shows that surface so you can review what your developers' agents have been extended with, and where it came from.
The page header shows the total number of plugins detected and the number of active devices reporting them. ### Filtering and Search **Agent chips** scope the list to **Claude Code** or **Codex**, with each chip showing how many plugins were detected for that agent. You can also search by plugin or publisher, narrow the table with three dropdowns, and use **Export CSV** to download the plugin inventory: * **All scopes**: where the plugin is installed: `User`, `Project`, `Local`, `System`, or `Unknown` * **Any source kind**: how the plugin was sourced: `Git or GitHub`, `URL`, `npm`, `Archive`, `Local`, `Account`, `Settings`, `Command`, or `Unknown` * **Any enablement**: `Enabled`, `Disabled`, or `Unknown` `Unknown` means the agent's own records did not say, so Dev Machine Guard reports the value as unknown rather than guessing. ### Plugin Table | Column | Description | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Plugin** | The plugin name, with its publisher beneath | | **Agent** | The AI agent the plugin is installed into: **Claude Code** or **Codex** | | **Marketplace · source** | The marketplace the plugin was installed from, a badge for the kind of source the plugin's files come from (for example `local`, `github`, `npm`, `account`, or `command`), and the path or repository they come from. A plugin that was not installed from a marketplace shows **No catalog**, for example an account-delivered plugin shown as `Account bundle` | | **Versions** | The plugin versions observed across your fleet | | **Enablement** | How many devices have the plugin enabled and how many have it installed but disabled, for example `7 enabled` | | **Components** | What the plugin supplies, counted by kind, for example `1 skill`, `1 command`, `1 MCP server` | | **Devices** | The number of devices where the plugin is installed | {% hint style="info" %} Installed and enabled are reported separately. A disabled plugin is still on the device, and can be turned back on without a new install, so it still appears in the inventory. {% endhint %} ### Plugin Detail View
Select a plugin to open its detail panel. The header shows the plugin name, the agent, the kind of source the plugin's files come from, and the publisher and marketplace, for example `Agent Plugin · Example Org · via engineering-catalog`. Cards at the top summarize the plugin across the fleet: | Card | What it counts | | ----------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Devices** | Devices where the plugin is installed | | **Installations** | Separate installations, counting user and project scope | | **Enabled devices** | Devices where at least one installation is enabled. A plugin that is installed but disabled everywhere shows `0` | | **Distinct components** | Distinct skills, commands, MCP servers, and other components the plugin supplies | #### **Plugin Information** The plugin's **Description**, **Publisher**, **Homepage**, and **Manifest name** from its manifest, the **Versions observed** across devices, a count of its **Components** by kind, and its **Plugin key**, a stable identifier you can copy. A field the manifest does not declare, such as a homepage, shows a dash. {% hint style="warning" %} Publisher, description, and homepage are self-declared manifest metadata, not verified trust signals. A plugin can name any publisher. Use **Source** to see where it actually came from. {% endhint %} #### **Source** Where the plugin was installed from: * **Marketplace**: the marketplace name, its source kind, and a link to the marketplace itself, for example a GitHub repository or a hosted `marketplace.json`. * **Plugin files from**: where the plugin's own files were fetched, for example a local path inside the marketplace or an npm package. The marketplace and the plugin files can come from different kinds of source. A plugin listed in a marketplace hosted on GitHub can ship its files from a path inside that marketplace, so **Marketplace** shows `github` while **Plugin files from** shows `Local` with a `path` badge. The badge in the panel header and in the plugin table describes the plugin files. #### **Installations** Every installation of the plugin, with the device, the installation **Scope** (**User**, **Project**, **Local**, **System**, or **Unknown**), the installed **Version**, its **State** (**Enabled** or **Disabled**), and when it was last observed. A device can appear more than once, for example with the plugin installed for the user and again for a project. #### **Components** Every component the plugin supplies, grouped by kind, such as **Skills**, **Commands**, and **MCP servers**, with a count of occurrences across the fleet. Each component is shown with its path inside the plugin, for example `skills/review/SKILL.md`. Use the toggle to view components **By kind** or **By device**. Each component row lists the devices it is present on, with the user account, installation scope, version, and state. For Claude Code skills, the row also shows how many times Claude Code has recorded the skill being used and when it was last used. `0 recorded uses` is a real count from Claude Code's own records: the skill is installed and has not been used. **View skill details** opens the skill on the [Agent Skills](/developer-machines/ide-and-ai-agents/agent-skills.md) page. {% hint style="info" %} Usage counts come from the cumulative counters Claude Code keeps on each device. Several copies of the same plugin on one device can share a counter, so counts are shown per device and never added together. {% endhint %} ### Plugins Across the Other Inventories Components supplied by a plugin also appear in the inventory for their type, attributed to the plugin: * On [Agent Skills](/developer-machines/ide-and-ai-agents/agent-skills.md), a plugin skill shows the plugin, its marketplace, and its agent in the **Source** column. * On [MCP Servers](/developer-machines/ide-and-ai-agents/mcp-servers.md), a plugin MCP server shows `Claude Code plugin` or `Codex plugin` as its config source, along with the plugin it comes from. Select the plugin on either page to open its detail view here. This answers the question those pages cannot answer on their own: whether a skill or MCP server was installed deliberately, or arrived as part of a plugin. ### How Plugins Are Detected Dev Machine Guard reads each agent's own record of installed plugins and configured marketplaces from local state, for both user and project scope, along with the plugin manifests and the component definitions they declare. For Claude Code, standalone commands and recorded skill usage are collected alongside. * **Nothing is executed.** The scan never runs a plugin, hook, script, or either agent's CLI, and makes no network requests. * **Instructions and secrets stay on the device.** Plugin metadata and definition hashes are reported. Skill and command bodies, credentials, and complete settings files are not uploaded. * **Relocated configuration is followed.** The `CLAUDE_CONFIG_DIR`, `CLAUDE_CODE_PLUGIN_CACHE_DIR`, `CLAUDE_CODE_PLUGIN_SEED_DIR`, and `CODEX_HOME` environment variables are respected where the agent can see them. * **A leftover cache is not an installation.** Old plugin files left in a cache directory are not reported as installed. * **Incomplete reads are reported as incomplete.** If a scope cannot be read, it is reported as incomplete coverage rather than as the plugin having been removed. ### Use Cases The Agent Plugins inventory allows you to: * See which plugins your developers have added to Claude Code and Codex, and on how many machines * Trace a plugin back to the marketplace and repository it was installed from, rather than trusting the publisher it declares * Find plugins installed from local directories or unlisted URLs instead of a known marketplace * Identify the plugins that bring MCP servers or hooks, which run code or reach external systems as the developer * Tell a plugin that is installed but disabled from one that is active * Respond to a compromised plugin or marketplace by finding every device that has it --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stepsecurity.io/developer-machines/ide-and-ai-agents/agent-plugins.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.