Skip to content
Claude Code Mods

Security and verification

What the checks on this site cover, what the proposed tier model would add, and what to check yourself.

What is checked today

Source verified

The source URL on an entry responded with HTTP 200 on the date the entry shows. The check is npm run catalog:verify, which requests every URL in the catalog and reports any that do not respond.

It does not read, scan or run any code. It says nothing about permissions, hooks, network calls, who maintains the project, or whether the description still matches the source after the check date.

Structure check on community submissions

When someone submits an entry by pull request, an automated check in CI confirms that the manifest files exist and parse: .claude-plugin/plugin.json for a plugin or a mod, and for a mod also hooks/hooks.json with a modules array. The command is npm run catalog:structure.

It checks that files exist. It is not a review of what they contain.

Warning

Source verified is not a security review. It does not mean the code is safe or endorsed by anyone.

Mods that ship inside Claude Code

The directory lists 4 mods published by Anthropic that ship inside Claude Code. As one example, sec-default is listed with this summary:

Keeps an organization's classic hooks, prompt content, managed settings and tool policy out of reach of user-installed plugins; adds no policy of its own.

This directory says no more about what it does than that text. Read the mod's own README for the details.

How Claude Code keeps a mod in check

Note

Function hooks are early access. This section restates what Anthropic's type declarations, the Mods README and the announcement say the engine does. This site did not test it, and the API may change between releases without notice.

A plugin that uses function hooks is loaded into one of five seats, outermost first. Claude Code calls these tiers in its declarations. This page calls them seats so they are not confused with the proposed tiers A, B and C in the next section, which have nothing to do with them.

  1. 1prependThe managed plugins an administrator lists first. The outermost seat.
  2. 2userEverything a person installs, as the declarations put it: a mod you load yourself sits here.
  3. 3appendThe managed plugins an administrator lists after the user seat.
  4. 4builtinThe plugins bundled in the Claude Code binary.
  5. 5coreThe engine's own innermost link. No plugin loads here.
Order is authority

Hooks on the same event nest in seat order and no other way. Earlier is outer, and outer has more authority. On the events whose result a hook can change, a hook above another can pass the event on, rewrite it, refuse it or answer it; on an event such as session.end a hook only observes, and its own value changes nothing.

Source: Mods type declarations (opens in a new tab)

Side effects go through $

A mod reaches files, the network and processes through calls on $. Each call is an event the engine makes, so the hooks above the caller see it. An administrator can remove affordances from $, so that every plugin beneath cannot use that side effect.

Source: Announcement issue (opens in a new tab), Mods README (opens in a new tab), Mods type declarations (opens in a new tab)

A failing hook is skipped

At every engine event, a hook that throws, overruns its time budget or answers a wrong shape is skipped: the hooks beneath and core run in its place, or its last next result stands, and the failure is reported by name. That means a guard that fails is absent for that dispatch, not that the call is refused. Each hook's time budget is its own code alone, and the clock stops while it waits on next(e) or on a call on $.

Source: Mods type declarations (opens in a new tab)

What this does not tell you

The seats govern what one plugin can do to another and to an organization's settings, and the README describes seating the security mod outermost on a machine with managed settings or for a Team or Enterprise organization. It does not say those are the only cases a plugin can be seated above yours: another user-seat plugin can be too. A mod you run from a folder is code you chose to run: read it first.

Source: Mods README (opens in a new tab)

sec-default is the mod in the directory that these seats are about. Its README says that, seated outermost, it keeps an organization's classic hooks, managed CLAUDE.md and rules, settings and MCP allowlist out of the reach of the plugins a person installs, and adds no policy of its own.

It has three moves and nothing else: continue past the user seat, refuse a user seat caller by name, or pass. Its README seats it first in the prepend seat on a machine with managed settings or for a Team or Enterprise organization, unless managed prependPlugins says otherwise, and says that loading it with --plugin-dir seats a plugin that can only pass.

Source: Security mod README (opens in a new tab)

Proposed security tiers

Warning

This is a design specification. No security scanner is running today, so no listing on this site has a tier.

The model below comes from the marketplace architecture spec. It describes a registry and a scanner that have not been built. Every tier and every CLI behavior in this section is a proposal.

TIER_AVerified

Passed static and dynamic audits, uses no elevated privileges, and comes from a trusted author.

Proposed CLI behaviorLoads and runs without asking.

TIER_BRestricted

Uses the workspace filesystem or a small set of allowed network endpoints.

Proposed CLI behaviorAsks the user before granting each declared permission, for example network access to a named host.

TIER_CExperimental

A community package that passes a syntax check but comes from an untrusted origin.

Proposed CLI behaviorNeeds an explicit trust step from the user. The report names a /mod trust command for this, which is not a confirmed Claude Code command.

REVOKEDRevoked

Failed the security criteria, or was reported for a vulnerability.

Proposed CLI behaviorRemoved from the listing and blocked by the CLI everywhere at once.

Proposed scan pipeline

The spec sends every published package through four checks, in this order, before it is listed. None of them runs today.

  1. Check package integrity

    Confirm the package is the one the author published and that its manifests are well formed.

    • Verify the author's Ed25519 signature against their public key.
    • Compare the tarball's SHA-256 checksum.
    • Validate the plugin.json and hooks.json schemas.

  2. Analyze the code statically

    Read the code without running it, looking for patterns the spec treats as dangerous.

    • Walk the TypeScript or Babel syntax tree.
    • Flag forbidden imports such as child_process, plus eval(), Function(), obfuscated strings and WebAssembly.
    • Compare the permissions the package declares with the API calls it actually makes.

  3. Run it in a sandbox

    Execute the package in an isolated environment and watch what it does.

    • Fire synthetic lifecycle events at it.
    • Monitor filesystem access and network calls that go outside its declared limits.
    • Check memory use and CPU time; the report proposes a budget of under 50ms per hook.

  4. Assign a tier

    Combine the results into one of the tiers above, or reject the package.

    • Clean results and a verified author lead to TIER_A.
    • Declared permissions that need user confirmation lead to TIER_B.
    • An unverified author or unconstrained network access leads to TIER_C.
    • A malicious pattern or a sandbox violation leads to rejection.

Before you install anything

Until something better exists, the checks are yours to make. They take a few minutes and apply to every extension, on this site or anywhere else.

  • Read the source

    Open the repository from the entry page and read what the package ships: commands, scripts, hook definitions and any bundled binaries. A short skill or command file takes minutes to read.

  • Check the publisher

    Confirm the publisher is who you expect and that the repository sits under their account or organization. Look-alike names and forks are a common way to pass off other code.

  • Review permissions and hooks

    Hooks run commands on their own when lifecycle events fire, and MCP servers run as local processes or talk to remote services. Find out which events a package hooks into and what it can reach before you enable it.

  • Prefer pinned versions

    Install a specific tag or commit instead of a moving branch or a latest tag, so a later push cannot change what runs on your machine. Try new extensions in a throwaway project first.

For where the data comes from and what it does and does not check, see About.