Claude Code Mods Can Rewrite Tool Calls. Treat Them Like Code You Run

A Claude Code mod is a small TypeScript function that hooks into what Claude Code does. According to Anthropic, it can block, rewrite, or retry a tool call, approve or deny a permission request, and redact secrets from tool output. It can also redraw parts of the interface.

That is useful. It is also a lot of power in a package you install with one command. Anthropic says plainly that mods run with the same access to your machine as Claude Code itself and are not sandboxed.

So the practical question is not "what can I build?" but "what would I be willing to let this code see and change?" I read the launch material to answer that for myself.

What is a mod, exactly?

Anthropic's launch post describes it this way: each time Claude Code does something, it emits an event. Calling a tool, asking for permission, and drawing part of the screen are examples. A mod hooks one of those events and can run before it, after it, instead of it, or wrap it.

Mods ship inside plugins, so you install and share them like any plugin. They work in the CLI and the desktop app. The getting-started guide by Addy Osmani on claude.dev lists Claude Code 2.1.287 or later as the requirement and says mods are on by default.

The guide gives each hook three moves:

• Observe: let the event pass through and look at the result.
• Rewrite: change the event before the rest of the chain sees it.
• Answer: return a denial without calling the next step, which refuses a tool call or serves it yourself.

Hooks form a chain, like middleware. When several mods hook the same event, Anthropic says they run in load order, so the first loaded sees the event first and the result last.

How is that different from settings hooks?

Claude Code already had hooks. Anthropic's post says they could not rewrite events, draw new UI, or replace features.

The guide adds that a settings hook runs a shell command for each event and passes JSON over stdin and stdout, while a mod is loaded once, stays in the session, can keep state, and can call back into Claude Code. It can open a pane, run a process, register a slash command, or register a tool the model can call.

For the same reason, a mod sits deeper in the loop than a shell hook. That depth is the point and the risk.

What does the security story look like?

There are three layers to read separately.

The module sandbox. The guide says a mod's module runs in a sandbox with no DOM and no Node, and everything outside goes through an API object. That limits how the module touches the world.

The plugin trust boundary. Anthropic's post says mods run with the same access to your machine as Claude Code and are not sandboxed, and that you should install mods only from sources you trust. The guide says a mod is written by its publisher, not Anthropic, and to read the repo first. I would not treat the two statements as contradictory. A sandboxed module can still hold powerful capabilities through the API it is given, such as running processes. Read the code you install.

Team controls. For Team and Enterprise plans, and any machine with managed settings, Anthropic says a built-in mod called sec-default loads first. It stops user-installed mods from doing risky things, such as overriding permission deny rules, and its source can be viewed. Admins can load their own mods first, and Anthropic says to include sec-default in that list to keep its restrictions. Admins can also allow or block plugin marketplaces.

Individual developers on personal plans do not get that layer by default, based on what Anthropic describes. You are the review process.

Why does rewriting a tool call matter?

Because a permission prompt is only meaningful if the thing you approve is the thing that runs.

If a mod can rewrite a tool call, the command you see and the command that executes can differ, depending on where the mod sits in the chain. If a mod can approve a permission request, a prompt you expected to see may never appear. I am not suggesting any published mod does this. I am saying the capability exists, which is why load order and source review matter.

The same capability is the upside. Anthropic's own examples of team uses include a mod that requires confirmation before any command touches production config and a mod that loads first and records every call other mods make.

One caveat in the guide's own example is worth copying. It describes a mod that holds dangerous commands for confirmation, then says it is "a safety net, not a permission system." It reads command text, so shell substitution, aliases, and scripts can get past it, and the guide says to use permission rules for a hard block.

That is the right mental model. A mod can add friction and visibility. A deny rule is what stops things.

How would I vet a mod before installing it?

This is my own checklist, built from Anthropic's descriptions, not an official procedure.

1. Read the manifest and module. Look at the plugin's hooks/hooks.json and the module it names. A small display mod should be short enough to read in one sitting.

2. List the events it hooks. A mod that only draws UI is a different risk from one that hooks tool calls or permission requests.

3. Look for process, file, and network calls. The guide lists the API surface a mod receives, including process and HTTP access. Check what the code actually does with them.

4. Check who published it. Anthropic says mods are written by their publishers. Prefer people and repositories you can evaluate.

5. Pin what you installed. Know the version and source so a later update does not change behavior unnoticed.

6. Keep deny rules in settings. Do not rely on a mod as your only barrier for destructive commands.

7. Prefer an audit mod first in load order. Anthropic describes this pattern for teams. It is one way to see what other mods do.

What I would take from this

Mods turn Claude Code into a platform. That is good for customization, and it moves part of your security model from "what does Claude do" to "what did I install."

The right habit is the one you already use for any package: read it, source it, and scope your protections so one bad install is not enough.

I wrote earlier about runtime permissions for agents. The same principle applies here: enforcement belongs in the layer the agent cannot rewrite.

FAQ

Are Claude Code mods sandboxed?

Anthropic says mods run with the same access to your machine as Claude Code itself and are not sandboxed, so you should install them only from sources you trust. The claude.dev guide separately says a mod's module runs without a DOM or Node and reaches outside through an API object.

Can a mod change a tool call?

According to Anthropic, yes. A mod can block, rewrite, or retry a tool call, and can approve or deny a permission request.

How are mods different from settings hooks?

Per Anthropic, hooks could not rewrite events, draw new UI, or replace features. The guide adds that a mod stays loaded in the session and can keep state, while a settings hook runs a shell command per event.

What is sec-default?

Anthropic describes it as a built-in mod that loads first on Team and Enterprise plans and on machines with managed settings. It stops user-installed mods from doing risky things like overriding permission deny rules.

Should I rely on a mod to block dangerous commands?

Not alone. The guide's own safety mod example calls itself a safety net, not a permission system, and says to use permission rules for a hard block.

Do I need to write mods myself?

No. Anthropic says you can ask Claude Code to write one and that it can install and hot reload it in your session. I would still read what it generated before keeping it.

Who publishes mods?

Publishers other than Anthropic, according to the guide. Anthropic says you can install plugins that include mods from the Claude directory or with /plugin, and that sharing means packaging a mod in a plugin.