Claude Code Mods: Programmable, Unsandboxed, and Your Problem in CI

Anthropic shipped mods for Claude Code: small TypeScript functions that hook into the tool's internal events and can rewrite a prompt before the model sees it, block or retry a tool call, approve or deny a permission request, redact secrets from tool output, or change what the interface draws. That turns a CLI agent into a programmable runtime instead of a tool you configure with flags. It is also, by Anthropic's own admission, code with the same native permissions as Claude Code itself and no sandbox. Our verdict: mods are worth adopting for the CI problems they actually solve, redaction and permission enforcement written as code instead of trusted defaults, but every mod you run is a CI step with your full runner access, and it needs that scrutiny before going near a pipeline.

What a mod actually is#

A mod is a TypeScript or JavaScript function, distributed inside a plugin and installed through the /plugin command, that registers handlers for events Claude Code fires internally: a prompt about to be submitted, a tool call about to run, a permission check, a render of a UI component. You can write one by hand or ask Claude to build one during a session. Mods ship inside the plugin system Anthropic introduced for Claude Code in late 2025, so a marketplace already distributing commands, subagents, and MCP servers now distributes mods too. Running them requires Claude Code v2.1.287 or later, and on that version they are on by default, with no separate flag.

The difference from a settings-file hook is reach. A hook reacts to an event; a mod sits inside the event pipeline and can rewrite the payload before anything downstream sees it, which is why a mod can redact a secret from tool output or substitute a different prompt entirely, not just log that something happened.

Why this matters specifically in CI#

The CI use case is obvious from the event list. Two problems teams running coding agents in pipelines have solved with brittle wrappers become native: redacting secrets from tool output before they land in a log artifact, and enforcing a permission policy (deny this tool, auto-approve that one) as code instead of hoping the default configuration holds. We covered the shape of this problem in running AI CLI agents in CI pipelines: the question that decides whether an agent belongs in a pipeline is what it can do that you did not approve. A well-written mod answers that in code, not documentation.

That is the upside case, and it is real.

The catch Anthropic put in writing#

The catch sits in the same sentence Anthropic uses to describe the feature: mods do not run in a sandboxed environment, and they carry the same native permissions as Claude Code itself. Anthropic's own guidance tells users to install mods only from trusted sources. A mod that touches the file system has your file system. A mod that spawns a process has your shell, meaning in a CI runner, deploy credentials and cloud tokens included.

The same shape as Plugin4Shell, deliberately#

Plugin4Shell was a bug where four coding agents, Claude Code included, checked out a pinned plugin commit but never verified the working tree landed on it, letting an attacker swap code after review. It got fixed. Mods are not a bug. They are a feature built on the premise that code from a plugin marketplace runs with full native access, by design, because that is what gives a mod the power to rewrite prompts and intercept tool calls at all. The posture is the one Plugin4Shell exploited; this time it is documented, intended behavior rather than a defect. That does not make it safer. It makes the trust decision the whole control, since no sandbox sits underneath to catch a mistake.

Here is the kind of mod a team would plausibly want in CI, a hook that strips an API-key pattern out of tool output before it reaches a log:

// mods/redact-secrets.ts (illustrative, not a working package)
import { defineMod } from "@anthropic-ai/claude-code-mods";

const SECRET_PATTERNS = [/sk-[A-Za-z0-9]{20,}/g, /ghp_[A-Za-z0-9]{36}/g];

export default defineMod({
  name: "redact-secrets",
  onToolOutput(event, ctx) {
    let output = event.output;
    for (const pattern of SECRET_PATTERNS) {
      output = output.replace(pattern, "[REDACTED]");
    }
    return ctx.replace(output);
  },
});

That is worth running in a pipeline. It is also exactly what a malicious actor would want installed, with one extra conditional that exfiltrates the match before redacting it. Reading the diff is the only control between those two files.

What we would actually require before CI adoption#

Treat a mod like a new GitHub Action, not a config flag:

• Pin the exact source. Reference a mod by commit SHA or a specific plugin version, never a branch or "latest." The checkout-doesn't-match-the-pin failure from Plugin4Shell applies here too: a pin nobody verifies is a label.
• Read the code before you run it. A mod that touches tool output or approves permission requests is operating with your credentials. Review it the way you would review a PR touching your deploy pipeline, because that is what it is.
• Never auto-install from a marketplace in CI. Vendor the mod into your own repository and install from that copy instead.
• Run it in the same contained environment as the agent. Our AI agent security guide covers scoped tokens and restricted egress; a mod inherits the agent's access, not a narrower one.

The decision, concretely#

• Want secret redaction or policy enforcement in CI? Write the mod yourself, or review a vendored one line by line; never take one from a marketplace unreviewed.
• Already running Claude Code in a pipeline with real credentials? Audit which plugins and mods are installed on that runner, the same way you would audit a set of GitHub Actions.
• Considering a marketplace mod a teammate found? Treat it like a new dependency: pin the exact source, read the diff, re-review every update.
• Running untrusted mods in CI at all? Don't, unless your container already assumes the agent process can do anything the runner's credentials allow.

The call we'd make#

Mods are a real upgrade for exactly the CI problems worth solving: redaction and policy enforcement written as code you control instead of defaults you hope hold. We would adopt them for that, written in-house or vendored and reviewed, never pulled live from a marketplace into a pipeline. The unsandboxed, native-permissions design is not a flaw to wait out, it is the deal, and the only thing standing between a useful mod and a malicious one is whether someone on your team actually read the code.