- What a mod is
- JavaScript/TypeScript event handlers that run inside Claude Code
- Shipped
- Claude Code v2.1.287 (terminal), Oct 1 2026; Desktop app from v2.1.286
- On by default; ships inside a plugin, installs through /plugin
- Not sandboxed
- a mod runs with your full user permissions
- Built-in mods
- /diff, agents-md, sec-default, telemetry, you-should-know
- Current as of October 2026; version-specific behavior moves weekly, re-check the changelog
Claude Code mods are small JavaScript or TypeScript functions that run inside Claude Code and change how it behaves, from rewriting a prompt before the model sees it to drawing a pane beside the transcript. They ship inside plugins, they're on by default, and they reach deeper than the older settings hooks because they run in Claude Code's own process instead of shelling out to a script.
Anthropic launched mods on October 1, 2026. They landed in Claude Code v2.1.287 in the terminal and work in the Desktop app's Code tab from v2.1.286. This page covers what a mod is, how it differs from skills, settings hooks, and plugins, and when to reach for each. Details are current as of October 2026, and Claude Code ships almost daily, so treat version-specific behavior as a snapshot.
What can a mod actually do?
A mod registers event handlers that Claude Code runs when something happens: a tool call, a submitted prompt, a turn, or a part of the interface being drawn. The handler can watch the event, rewrite it, or take it over so the usual behavior never runs. That in-process position is the whole point. It lets a mod do what a script running outside Claude Code cannot:
- Rewrite a prompt before the model sees it.
- Hold, block, rewrite, or retry a tool call, or answer it without running the tool.
- Approve or deny a permission request.
- Redact secrets from tool output.
- Draw an interface: a pane beside the transcript or a band above the prompt, with buttons and text fields.
- Redraw parts Claude Code draws itself, such as a tool-call row or the spinner.
- Add a
/commandthat runs your function immediately, with no model turn. - Route a single request to a different model.
Here is the minimal mod from Anthropic's docs. It counts tool calls and shows the running count beside the spinner:
// hooks/register.js: count tool calls, show the count beside the spinner
let calls = 0
export function register(on) {
on('tool.call', async ($, e, next) => {
calls += 1
$.ui.invalidate('ui.render')
return next(e)
})
on('ui.render', { component: 'Spinner' }, async ($, e, next) => {
return next({ ...e, props: { ...e.props, suffix: ' · tool calls: ' + calls } })
})
}
Mods vs skills vs settings hooks vs plugins
Four names get conflated. Three of them change behavior; the fourth is just packaging.
| Mod | Settings hook | Skill | Plugin | |
|---|---|---|---|---|
| What it is | JS/TS functions Claude Code runs in its own process | A shell command, HTTP request, or prompt run on a lifecycle event | A SKILL.md file of instructions Claude reads | The package that bundles any of the above |
| What it changes | Tool calls, prompts, turns, commands, and what the UI draws | Whether a tool call or prompt proceeds, a call's arguments and result, context added for Claude | What Claude knows and does | Nothing on its own; it's distribution |
| Draws UI | Yes | No | No | N/A |
| You write | JavaScript or TypeScript | A script plus a settings.json entry | Markdown | A manifest plus the components |
| Reach for it when | You want a pane, a band, a custom command, or to rewrite an event in code | You want to block, allow, or log an event with a script you already have | You keep pasting the same instructions | You want to share or install any of these |
The relationship matters more than the row-by-row differences: a plugin is the box, not a behavior. Mods, skills, commands, agents, settings hooks, and MCP references all ride inside a plugin, which is how they install and distribute through /plugin and the Claude directory. For the skills, agents, and MCP side of the map, see our skills vs agents vs MCP breakdown.
How is a mod different from a settings hook?
Most people get this wrong, partly because Anthropic reuses the word "hook" for both. A mod's handlers are hooks; the configured kind is a settings hook.
A settings hook runs outside Claude Code as a script, HTTP request, or prompt set in a settings file. It can decide whether a tool call or prompt proceeds, change a call's arguments and result, and add context for Claude. What it can't do is draw an interface or run logic inside the process. A mod does all of that in code: it rewrites events, renders panes and bands, adds commands, and can route a request to a different model. If you already have a script that gates or logs an event, a settings hook is still simpler. Reach for a mod when you want UI or in-process control.
What ships built in?
Some of Claude Code's own features are already mods, which is the clearest proof the system is real and not a toy. Run /plugin and open the Installed tab to see them under Built-in:
cc-plugin-difftakes over/diffand draws its pane. Disable it and the built-in command answers instead.cc-plugin-agents-mdloadsAGENTS.mdas project instructions.cc-plugin-sec-defaultguards organization-managed settings from the mods a user installs.cc-plugin-telemetrysends the analytics Claude Code logs.cc-plugin-you-should-knowruns a side agent that flags things you or Claude might miss. It's off by default; enable it with/plugin enable cc-plugin-you-should-know@builtin.
The source for four of these (diff, agents-md, sec-default, telemetry) is public in the anthropics/claude-code repo, and Anthropic ships three sample mods (token-weather, blast-radius, replay-theater) in the claude-code-playground repo you can clone and load for a session.
Are mods safe to run?
Slow down here. Mods are not sandboxed. Per Anthropic's docs, a mod runs with your full user permissions, which means a mod you install can:
- Read and write any file your account can, start programs, and make network requests.
- Read your environment variables and settings, including an API key kept in either.
- See every prompt you send and every tool call Claude makes.
- Approve a tool call before you're asked, including one an
askrule would stop. - Spend your plan or API usage.
There is one hard boundary: a mod can restyle most of the interface but not the permission prompt. Sandboxing, if you turn it on, isolates the Bash commands Claude runs, and a process a mod starts runs outside it. So the trust model is the one Anthropic states plainly: install mods only from authors and marketplaces you trust, the same way you'd install any code on your computer. Before you load one, run claude plugin validate ./some-mod to list the events it handles and the calls it makes. That is the same vetting discipline third-party skills and plugins already need, now with higher stakes because a mod can rewrite what you see.
When should you reach for a mod?
Match the tool to the gap:
- You want Claude Code to look or behave differently (a context-usage pane, a confirm step on risky commands, a custom
/command): write a mod. - You want to block, allow, or log an event with a script you already maintain: a settings hook is enough.
- You keep re-explaining the same procedure: write a skill, the approach our best Claude skills roundup covers.
- You want to share any of the above: wrap it in a plugin and submit it to the directory.
Mods are the first layer that lets you change Claude Code itself, not just what it knows or which events it reports. That is also why the security line matters: a mod is code with your keys, running inside the tool you trust most.
- https://claude.com/blog/claude-code-mods
- https://code.claude.com/docs/en/plugins/mods/overview
- https://code.claude.com/docs/en/changelog
- https://code.claude.com/docs/en/hooks
- https://github.com/anthropics/claude-code/tree/main/mods
- https://github.com/anthropics/claude-code-playground/tree/main/claude-code/mods
