How to audit the plugins, hooks and MCP servers your AI coding agent loads

In short

AI coding agents such as Claude Code and Codex can load plugins, skills, hooks and MCP servers, and an enabled one is part of every session, not only the sessions where you use it. A hook runs commands on your machine with your user privileges; a skill or session-start text is injected into the model's context as instructions. To audit your setup, list four things in each agent: enabled plugins, hooks, MCP servers and the marketplaces they came from. Both tools have built-in commands for that (/hooks, /plugin, claude plugin details), and both let you disable or remove what you do not trust.

Why audit this at all

An agent's configuration decides what runs on your laptop and what text the model reads before it sees your request. Most of the time that is exactly what you want. But the surface is easy to change without noticing: a plugin can be installed by a tool other than the agent, a marketplace can auto-update a plugin you reviewed last month, and project settings can add hooks for everyone who clones a repository.

A recent example is the report that Postman's desktop app added plugins and a session-start hook to Codex and Claude Code. We use it here only as a prompt to look; the habits below apply to any plugin from any vendor, and to your own team's repositories.

The four things an agent loads

1. Plugins and marketplaces

Claude Code's documentation defines a plugin as a directory of skills, agents, hooks, MCP servers or other components that is installed and loaded as one unit. Plugins come from a marketplace, which is a catalog with a .claude-plugin/marketplace.json file that lists plugins and where to fetch each one. A marketplace's name tells you who publishes the catalog, not what each plugin does. Anthropic reserves certain marketplace names, such as claude-plugins-official, for repositories under github.com/anthropics/, and every other marketplace is third-party. Whatever the tier, the documentation is blunt: a plugin you install can execute arbitrary code on your machine with your user privileges.

Plugins have an install scope. User scope enables a plugin for you in every project on the computer; project scope enables it for everyone who works in a repository through the committed .claude/settings.json; local scope enables it for you in one repository only.

2. Hooks

Hooks are handlers that run automatically at fixed points in an agent's lifecycle. In Claude Code a handler can be a shell command, an HTTP endpoint, an MCP tool call, an LLM prompt or a subagent. The SessionStart event runs when a session begins or resumes, and its matcher selects how the session started: startup, resume, clear, compact or fork. A hook that matches startup|clear|compact therefore fires at the start of a session and again each time you clear or compact it.

Claude Code reads hooks from several places: ~/.claude/settings.json (all your projects), .claude/settings.json (one project, shareable), .claude/settings.local.json (one project, not committed), managed policy settings for an organization, and the hooks/hooks.json file of any enabled plugin. These sources merge rather than override each other, so a hook in one layer is not removed by a setting in another.

Codex discovers hooks in ~/.codex/hooks.json, ~/.codex/config.toml, <repo>/.codex/hooks.json and <repo>/.codex/config.toml, and enabled plugins can bundle hooks too. Project-local hooks load only when that project's .codex/ layer is trusted.

3. MCP servers

A plugin can declare MCP servers, which Claude Code connects to while the plugin is enabled. A stdio server runs as a process that Claude Code starts on your machine; a remote server is a URL. Read the plugin's .mcp.json to see each server's command or URL.

4. Skills and injected context

Skills, commands and agents enter the model's context as instructions, so they influence what the agent does with tools it already has. For each skill the agent may invoke on its own, the name and description sit in context on every turn, which costs usage and context window space even in sessions where the skill never runs. A session-start hook goes further: Codex's documentation says plain text printed on stdout by a SessionStart hook is added as developer context.

How trust works in each tool

Claude Code. The documentation says hooks run with your privileges and inherit the parent environment, with a few exceptions. Hooks fail open by default: most failures or timeouts let the action proceed, and since version 2.1.295 you can set "onFailure": "block" on command or HTTP hooks to block instead. Project hooks defined in frontmatter run only after you accept the workspace trust dialog. Permission rules and the sandbox cover the tool calls Claude makes, not the code a plugin runs by itself: hooks, monitors and server processes run outside the sandbox.

Codex. Per OpenAI's documentation, non-managed hooks must be reviewed and trusted before they run. Codex records trust against the hook's current hash, so new or changed hooks are skipped until trusted, and if a plugin update changes a bundled script, a new review is required even when the hook definition is unchanged. The page describes /hooks for inspecting and trusting hooks, a startup warning when hooks need review, and a --dangerously-bypass-hook-trust flag for one-off automation that vets hooks elsewhere. A reported trust record on disk is what the Postman issue discusses; the documentation page we read does not name the config keys involved, so we do not describe them here.

Both vendors also note that hooks are a guardrail rather than an enforcement boundary. Claude Code's page says to use the permission system, not hooks, for hard allow and deny rules; Codex's says to treat tool hooks as "a useful guardrail, not a complete enforcement boundary".

A five-minute audit

Do this for each agent you use. Everything below only reads state until the final step.

Step 1: list hooks.

• Claude Code: type /hooks in a session. It is a read-only browser that labels each hook by source (user, project, local, plugin or session) and shows the exact command and where it is defined.
• Codex: type /hooks in the CLI to inspect sources, review and trust hooks, or disable individual non-managed hooks.

Step 2: list plugins and marketplaces.

• Claude Code: run /plugin in a session and open the Installed tab, or run claude plugin marketplace list in your shell to print the source each marketplace was added from. For an installed plugin, claude plugin details <plugin name> prints a component inventory: skills and commands, agents, hooks with each hook's event, and MCP and LSP servers.
• Both tools: search your settings files for names you do not recognise. A quick start is grep -n -i <vendor> ~/.codex/config.toml ~/.claude/settings.json.

Step 3: read what hooks and servers actually run. The "Will install" pane in /plugin shows that a hook exists but not what it runs. Open the plugin's hooks/hooks.json for the command each hook executes, .mcp.json for each server's command or URL, and every file in bin/, because Claude Code adds an enabled plugin's bin/ directory to the PATH of the Bash tool's shell.

Step 4: check project-level config before you trust a repository. Look at .claude/settings.json and <repo>/.codex/ in any project you clone. Project settings are shareable by design, which means a repository can ask your agent to run hooks.

Step 5: remove or disable.

• Claude Code: claude plugin uninstall <plugin> with the --scope you installed it at. Files stay under ~/.claude/plugins/cache/ for 14 days before a background sweep, so delete ~/.claude/plugins/cache/<marketplace>/<plugin>/ yourself if you want them gone now. To stop a plugin without uninstalling, run claude plugin disable. To turn all hooks off temporarily, set "disableAllHooks": true in a settings file; there is no way to disable one hook entry while keeping it in the configuration, so delete the entry to remove it.
• Codex: hooks are enabled by default; set hooks = false under [features] in config.toml to turn them off, or disable individual non-managed hooks from /hooks.

Before editing a settings file by hand, make a copy and review the diff afterwards.

Habits that keep it manageable

• Prefer fewer plugins. Each enabled plugin adds context cost, processes and hooks to every session. Claude Code's Installed tab has a "Not used recently" group of candidates to switch off.
• Know your update path. When auto-update is on for a marketplace, Claude Code updates the plugin in the background, so the files you reviewed can change. Turn auto-update off per marketplace if you want to review changes.
• Pin and review in teams. Organizations can allowlist or block marketplaces, force-install plugins, and limit hooks to managed settings with allowManagedHooksOnly in Claude Code, or allow_managed_hooks_only = true in Codex.
• Keep secrets out of hook output. Codex saves oversized hook output to a temporary directory, so avoid printing secrets from hooks.
• Treat vendor installers as writers of your config. Any desktop app can write to your home directory. After installing developer tools, re-run the audit.

What this guide does not cover

We did not test these commands on every operating system or version, and tool behavior changes quickly; the vendors' pages linked below are the authority. Neither vendor's documentation, as we read it, promises that other software cannot write to your agent's configuration files, so the audit above is the dependable control.

Sources

• Claude Code: Hooks reference
• Claude Code: Plugins overview
• Claude Code: Plugin security and trust
• Codex: Hooks
• postmanlabs/postman-app-support issue #14370