Claude Mods: Setup, Function Hooks and Security

Claude Mods are Claude Code plugins that use function hooks to extend the agent's runtime behavior, rather than only supplying instructions or external tools. They can participate in engine events and interface rendering. The practical question for a team is not whether a demo looks impressive, but whether the extension solves a repeatable problem without making permissions, debugging or upgrades harder.

Research date: 16 September 2026. This is a documentation and source-code review, not a hands-on benchmark. We distinguish the published API and experimental access from general availability, and mark our rollout recommendations as engineering guidance rather than Anthropic guarantees.

Are Claude Mods available yet?

Experimental access is documented, but a stable general release is not established by the sources reviewed. In the official Claude Mods announcement, the 9 September update names the feature, points to built-in examples and publishes CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 claude for testing. The same update describes broader shipping on a timescale of weeks. The original proposal was posted on 3 September 2026.

The official Mods source directory explicitly labels the interface early access and warns that APIs may change between releases without notice. Its examples are source listings for built-in functionality, not entries in that repository's plugin marketplace. Our recommendation: evaluate Mods in a controlled pilot, not as a dependency with an assumed stable support contract.

There is also an unrelated community repository named 0xDarkMatter/claude-mods. Do not confuse that collection with Anthropic's native function-hook feature, or assume that installation instructions for one apply to the other. In this article, “Claude Mods” means Anthropic's feature.

Claude Mods vs Skills, MCP, plugins and classic hooks

These mechanisms solve different problems. Anthropic's Skills documentation describes reusable instructions and workflows; its MCP documentation covers connected tools and data. The existing hooks reference already supports decisions at applicable pre-execution events. Mods do not invent the ability to stop an action. The plugin documentation describes the packaging and distribution layer that can contain several extension types.

A Mod is a kind of plugin, not a replacement for the plugin system. Our selection rule is to start with the least powerful mechanism that meets the acceptance criteria. For example, a Claude Code design-system context stack is normally a better starting point for brand consistency than custom runtime code. Connect an external service through MCP before considering whether a Mod adds something the integration actually lacks.

How function hooks work: events, the engine interface and next

The published source describes a module entry point, register(on, options), whose handlers receive ($, e, next). Read e as the event, $ as the engine interface available to that handler, and next as the continuation through the remaining chain. This is closer to middleware than a longer system prompt.

The published TypeScript declarations inspected for this review identify Claude Code 2.1.273. They describe a hook environment without Node.js or a browser DOM, with supported capabilities mediated through the engine interface. UI elements come from the relevant surface, rather than arbitrary access to a web page. Regenerate declarations with /plugin-types after an upgrade instead of assuming yesterday's types still fit.

Order matters. A wrapping handler can act before delegating, then inspect the returned result. Nested handlers can therefore interact even when each looks reasonable in isolation. For our own implementation reviews, we would explicitly check which layer owns a denial, whether a retry repeats a side effect, and whether the continuation is invoked exactly as intended. Do not treat “TypeScript compiles” as evidence that those interactions are correct.

The absence of a direct Node.js API is also not a complete security argument. A Mod with access to a powerful mediated tool still needs a carefully scoped trust boundary. Permissions, network restrictions, data handling and administrative configuration must be reviewed separately.

What do the three published built-in Mods demonstrate?

sec-default: protect organization-managed configuration

The sec-default source documentation describes an outer administrative layer that keeps selected managed settings, prompt content, classic hooks and tool policy beyond the reach of user-installed plugins. It adds no new business policy of its own. Importantly, many other events pass through unchanged: this is not a general firewall for every tool call.

Its position in the chain is part of the protection. The documented default seating changes when an organization supplies its own prependPlugins list; administrators then need to account for sec-default@builtin explicitly. Loading the folder locally is not equivalent to installing an organization-managed control. Our takeaway is to review the complete managed configuration, not just one reassuring plugin name.

diff: a real interface extension

The diff Mod renders uncommitted changes and file hunks beside the transcript, updating the pane as edits and commands occur. This demonstrates a concrete UI use case, rather than a claim that a plugin makes the underlying model smarter. The source also describes handling a non-Git directory and an already registered /diff command, useful edge cases for anyone building a similar pane.

telemetry: published source does not mean publicly installable

The telemetry Mod's own README is more restrictive than a quick glance at the directory suggests. It says the Mod runs on internal builds with analytics enabled and is not intended for standalone installation with --plugin-dir. Its analytics capabilities are not a general-purpose public logging service. Treat it as an architectural example, not an installation recommendation for customer environments.

How to try Claude Mods without assuming a stable API

Use a disposable project with synthetic data, an approved Claude Code installation and no production credentials. These are source-documented commands, not a claim that we executed them in a live Claude session. Support depends on the installed build and the organization's controls.

claude --version
CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 claude

Record the version and, inside a compatible session, run /plugin-types. Keep the generated declarations with the pilot's test evidence. If the command or feature is unavailable, stop and check supported access with your administrator; do not disable managed protections to make an example work.

For source inspection, use a reviewed revision of the official repository. From that checkout's root, the documented diff example and test harness can be invoked as follows, with the experimental flag applied to each process:

CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 claude --plugin-dir ./mods/diff
CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 claude plugin test ./mods/diff

The already built-in /diff can affect which implementation owns the command. Loading a directory is therefore not sufficient proof that a particular handler ran. Establish the active implementation through tests or explicit non-sensitive diagnostic evidence.

A published Mod is an ordinary plugin directory with a manifest and a hooks module:

my-reviewed-mod/
├── .claude-plugin/plugin.json
├── hooks/
│   ├── hooks.json
│   └── register.ts
└── tests/

The official diff hooks.json points to its module through the following field. This is a loader fragment, not a complete working plugin or a security control:

{
  "modules": ["./register.ts"]
}

Build the entry point against your generated declarations, add tests and review the complete source before loading it. Avoid invented commands such as a supposed universal Mod installer. For distribution, follow the supported plugin mechanism and your organization's approval process, not an arbitrary script found through a search result.

Where could Claude Mods create practical value?

The following are proposed pilot designs, not reported Wavect deployments or guaranteed built-in features. Each starts with an observable outcome rather than the goal of “adding more AI”.

A review pane for delivery evidence. Show the current change, test status and unresolved review findings in one place. Begin read-only. Accept the pilot only when each status can be traced to the exact revision and test run, and stale evidence is visibly rejected. An attractive green indicator without that connection is worse than the original terminal output.

Controlled treatment of sensitive tool output. A team might transform data before it reaches the model. Our acceptance criterion would be to trace synthetic canary values through the raw response, transformation, model input, visible transcript and logs. Masking a value on screen is not the same as removing it from model context, and neither alone proves that stored copies were removed.

Organization-specific workflow controls. A Mod could complement existing controls with contextual checks or explanations. Keep actual deployment authorization, repository protections and credential scope outside a user-removable convenience layer. First establish whether a classic hook or the existing CI pipeline already meets the requirement with less custom code.

What security boundaries should a team test?

Anthropic's Claude Code security guidance and sandboxing documentation describe controls beyond individual plugins. Review those controls independently. A restricted hook environment, a safe-looking interface and an approved marketplace entry answer different questions; none should silently substitute for the others.

These are acceptance requirements to implement and verify, not assertions about every current failure mode. In particular, never infer fail-closed behavior from a normal successful run. Test the denied and unavailable paths deliberately, with credentials that cannot reach production.

For supply-chain review, use the official plugin-marketplace documentation alongside your source review. Record the publisher, reviewed revision, dependencies, requested capabilities, update route and revocation procedure. Test the combination you will actually deploy, including administrative layers and other plugins, rather than approving each component only in isolation.

Do Claude Mods reduce token costs or improve productivity?

There is no measured savings percentage in this review. Anthropic's cost documentation explains Claude Code usage costs, but a Mod is not itself a pricing discount. Our assessment would count additional tool calls, context, retries, development effort and maintenance alongside any removed manual steps.

A useful pilot metric is total cost per accepted task: attributable model and tool charges plus engineering and review time, divided by tasks that pass the same acceptance criteria. This is our evaluation method, not an Anthropic billing formula. Compare a baseline and a Mod-enabled run on the same task set, model configuration and quality bar. Report failures and regressions, not only the fastest successful example.

A pilot that saves interaction time but produces more rework may be a net loss. Conversely, a small improvement on a frequent, expensive review step can justify a narrowly scoped Mod. Define the target improvement and acceptable maintenance burden before building.

Should your team adopt Claude Mods now?

Pilot Mods when you have a specific runtime or interface limitation, controlled test data, a responsible owner and a way to roll back. Wait when the requirement is already met by Skills, MCP, a classic hook or CI, or when the extension would become the only barrier protecting a production system. Our recommendation is to make a small, reversible experiment earn its place through evidence.

At Wavect, we approach this through AI enablement for engineering teams: identify the workflow, define acceptance tests and connect the outcome to delivery quality. Our Twinsoft AI case study provides separate evidence of our AI delivery work; it is not presented as a Claude Mods implementation. The pre-launch software QA checklist is a useful baseline for the wider product changes an agent makes.

For company background, our September 2026 ranking record documents Wavect's #1 Austrian category positions on Clutch, The Manifest and GoodFirms, with category-specific sources and dates. Directory positions are not a guarantee of results or evidence that we have deployed this new feature. For a concrete pilot, bring us one workflow and its acceptance criteria.