A mod changes the Claude Code program itself. It’s a bit of JavaScript or TypeScript that runs inside Claude Code and gets called when something happens: you submit a prompt, Claude calls a tool, or part of the screen is drawn. It can let the event go through, change it, or handle it instead.
The others change different things:
- A skill changes what Claude knows. It’s instructions Claude reads.
- An MCP server changes what Claude can reach. It gives Claude new tools.
- A settings hook runs a script at fixed moments, like before a tool call.
- A plugin is the box you install. It can hold any of the above, mods included.
When mods came out on October 1, my first question was how they fit with the skills and MCP servers I already use. This is what I worked out from the official docs.
The four side by side
This is Anthropic’s own comparison, trimmed a little:
| Mod | Settings hook | Skill | MCP server | |
|---|---|---|---|---|
| What it is | Functions that run inside Claude Code | A script, HTTP request or prompt that runs on an event | A SKILL.md file of instructions | A separate program that gives Claude tools |
| What it changes | Tool calls, prompts, commands, turns, and the interface | Whether a tool call or prompt goes ahead, and what it sends and returns | What Claude knows and does | Which tools Claude has |
| Can it draw on screen | Yes | No | No | No |
| What you write | JavaScript or TypeScript | A script plus a settings.json entry | Markdown | A server in any language |
| Pick it when | You want a pane, a custom command, or to rewrite an event | You want to block, allow or log something with a script you have | You keep pasting the same instructions into chat | Claude needs to reach an outside system |
Source: Compare mods, settings hooks, skills, and MCP servers.
The easiest way I found to remember it: a skill is a note for the model. An MCP server is a new tool in the model’s hands. A hook and a mod are changes to the program the model runs in. A mod just goes much further than a hook.
One example, four ways
Say you don’t want Claude to read the secrets in your .env file.
- With a skill, you write “don’t open
.env” in the instructions. Claude will usually follow it, but it’s a request to the model, not a rule. - With an MCP server, there isn’t much to do. MCP adds tools. It can’t take away Claude Code’s own file tools.
- With a settings hook, you run a script before every file read and block
any read of
.env. Now it’s a rule the program enforces. (Claude Code’s permission rules can do the same simple block without a script.) - With a mod, you can block the read too. You can also replace secrets with placeholders in anything Claude reads, and draw a small pane that lists what was hidden. That last part, showing something on screen, only a mod can do.
So for “should this happen at all”, a hook or a permission rule is often enough. Mods are for when you want to change how Claude Code works or looks.
What only a mod can do
From the docs, the things the other three can’t:
- Add interface. A pane beside the conversation, or a band above the prompt, with buttons and text fields.
- Redraw Claude Code’s own interface. Restyle messages, tool rows or the spinner. The permission prompt is the one part a mod can’t change.
- Step into a request. Answer a tool call without running the tool, or send one request to a different model.
- Run a command instantly. A
/commandthat runs your code right away, without a Claude turn, even while Claude is working. - Keep state between events. One part of a mod counts tool calls, another part shows the count beside the spinner.
Some of Claude Code’s own features are now mods. /diff is one, and so is the
part that loads AGENTS.md. You can turn them off in /plugin.
The price for all this: a mod runs with your permissions and isn’t sandboxed. It can read your files and secrets, see every prompt, and approve tool calls before you’re asked. A skill can at worst mislead the model. A bad mod is a bad program on your computer. I wrote more about checking one before you install it in Best Claude Code Mods to Try First.
Where plugins fit
A plugin is how all of these get packaged and installed. One plugin can hold
skills, settings hooks, MCP servers, subagents and mods, and you install it
with /plugin install
(plugins docs).
So “mod vs plugin” isn’t really a choice. A mod always ships inside a plugin. The plugin is the box; the mod is one kind of thing you can put in it, next to a skill that tells Claude when to use it and an MCP server that fetches the data it shows.
Which ones work outside Claude Code?
This is the difference I care about most, because I don’t write with only one agent.
- Skills are folders with a
SKILL.mdfile. Codex reads skills too, so one skill folder can serve both. - MCP is an open protocol. Claude Code, Codex, Cursor and others can all connect to the same server.
- Settings hooks and mods belong to Claude Code. A mod written against Claude Code’s events and interface doesn’t carry over to another agent.
If something should work in whichever agent you open, put it in a skill or an MCP server. If it’s about how Claude Code itself feels to use, that’s what a mod is for.
That’s also how StashBase is built. It works with both Claude Code and Codex, so it gives agents your files through MCP and its writing help as a skill, which either agent can use.
The fastest way to understand a mod
Ask Claude Code to write one:
Make a mod that shows the current git branch above the prompt.Claude uses its built-in plugin-authoring skill, writes a few small files,
and asks you to enable the mod for the session
(how it works). Reading
those files shows you exactly how a mod hooks into the program.