On October 1, 2026, Anthropic announced "Mods," a way to extend the behavior and interface of its AI development tool Claude Code. Functions written in JavaScript or TypeScript can be bundled into a plugin to rewrite tool calls or add a control panel beside the conversation view. Existing extensions let Skills teach the AI work procedures and let MCP connect it to external tools. Mods go further, allowing developers to step into Claude Code's internal processing flow. However, because a Mod runs with the same permissions as the user, deciding which Mod gets access to what is left to users and organizations.
Not just adding instructions, but changing the processing flow itself
Mods work by registering functions against events in Claude Code, such as calling a tool, receiving a prompt, or rendering part of the screen. A function can observe the process and pass it along unchanged, or rewrite the input before passing it on. It can also skip the normal processing entirely and have the Mod return the response itself. The official event documentation describes this as a chain in which each function calls the next step.
For example, when Claude is about to run a shell command, a Mod can pause the process and display the command's potential impact. If the user approves, execution proceeds; if the user declines, the command is never passed to the tool. A Mod can also receive a tool's output and redact secrets before it reaches Claude. This differs fundamentally, in where control sits, from telling the AI in a prompt to "avoid dangerous operations."
When multiple Mods handle the same event, a Mod that runs earlier can step in before and after the downstream processing. Because it can inspect input before calling the next step and receive the result afterward, logging and restriction logic can be placed in an outer layer. On the other hand, if a Mod returns a response without calling the normal processing, nothing after it runs. The order in which Mods are applied therefore matters.
The difference from existing Hooks deserves attention. Hooks, which are used through settings files, can also decide whether a tool may run and rewrite its arguments or results. What Mods add is the ability to rearrange the processing flow from functions running inside Claude Code, share state, and even build screens the user can interact with. Organized in a form that helps developers choose, the official comparison looks like this:
| Extension method | What it mainly changes | Best suited for |
|---|---|---|
| Skills | Instructions and work procedures the AI reads | Teaching recurring internal rules or specialized tasks |
| MCP servers | External tools the AI can use | Connecting to ticketing systems, databases, and the like |
| Settings Hooks | Commands, HTTP requests, and so on run on events | Denying, allowing, or logging operations using existing scripts |
| Mods | Processing flow of internal events, and the interface | Adding custom panels, rewriting processing, implementing responses that replace normal processing |
Source: comparison table in Mods overview. A plugin is the unit for distributing these features together; a single plugin can include Mods, Skills, and MCP servers.
In short, MCP remains the right fit if you only need to connect to an external system, and Skills if you want to teach the AI a set procedure. Mods are for when you want to change both what the user sees while working and how Claude Code carries out its processing.
Confirmation UIs and a watchful monitor, right inside the workspace
The samples Anthropic published illustrate well how Mods combine internal events with the interface. "Token Weather" shows context usage above the input field. "Blast Radius" pauses dangerous shell operations such as deletions and force pushes, shows their impact, and asks the user whether to run or cancel them. "Replay Theater" records Claude's edits and displays a screen for reviewing the changes in order. Official creation guide
If such displays were left to a separate tool, users would have to move back and forth between Claude Code and that tool. With a Mod, the information needed for a decision and the action buttons can appear right where the operation was stopped. These are, however, samples showing how Mods can be used, and the official documentation states that they are provided without support. They are not guaranteed to detect every dangerous operation.
Claude Code's built-in diff view, /diff, is also implemented as a Mod. Anthropic has indicated a direction of moving more built-in features into Mods and adding needed functionality around a small core. Still, only the code for some built-in Mods has been made public; Claude Code as a whole has not been open-sourced.
Version 2.1.287 also adds a built-in Mod called "You should know," in which a separate agent monitors the work. During long tasks, it notifies the user when it detects something that the user or Claude might overlook. It is disabled by default, and according to the official changelog, conditions for use include having telemetry enabled in sessions that connect directly to Anthropic's services. Where available, it can be enabled with /plugin enable cc-plugin-you-should-know@builtin. Official changelog
Usage also differs between a Mod that only displays a screen and one that runs an additional model. Counters and control panels can be updated without calling a model, but calling a model through the Mods API uses the user's plan or API key. Mods do not necessarily run without extra model usage. Mods API
Rules that stop Claude's tools are separate from a Mod's own permissions
Mods can read and write files and launch processes with the same permissions as the user. The environment that runs a Mod's code has neither Node.js nor the DOM, and external operations go through dedicated APIs. These constraints on the execution environment, however, do not amount to a sandbox that isolates a Mod from the user's OS permissions. Anthropic's administrator documentation also states that an approved Mod runs with the user's permissions.
When signed in with a Team or Enterprise account, or when managed settings are applied to the device, a built-in Mod called "sec-default" is loaded before user Mods. When using an API key or a third-party API platform, the condition for loading is that the device has managed settings applied.
The default sec-default prevents user Mods from changing a Claude tool call that violates a deny rule into an approval. It also cannot let through operations denied by managed PreToolUse Hooks. If a Mod rewrites the contents of a tool call, the managed Hooks check the modified contents again. Official administrator documentation
The mechanism that restricts Claude's tool calls and the mechanism by which a Mod itself accesses files and processes are separate paths.
Based on Anthropic's administrator and API documentation, the controls that apply to each kind of operation can be organized as follows:
| Operation path | Controls and limits described in the official documentation |
|---|---|
| Claude reads a file via a tool | With the default settings where sec-default is active, denials from deny rules and managed Hooks take precedence |
A Mod reads a file directly with $.fs.read |
Deny rules for Claude's tools do not apply; the Mod can access any file the user can read |
A Mod communicates with $.http.fetch |
The organization's restrictions on web fetching and communication apply |
A Mod launches a program with $.process.run |
Restrictions for $.http.fetch do not apply to communication by the launched program |
Sources: administrator documentation on default behavior and existing controls, API section on files, processes, and the network. This summarizes the official specifications as confirmed on October 4, 2026, and is not the result of safety testing on actual devices. The actual scope of access may vary depending on an organization's own Mods and settings, as well as OS-level controls.
The example in the official documentation is concrete. Even if a rule prevents Claude's Read tool from reading .env, a Mod can still read that file itself using $.fs.read. When introducing a Mod that redacts secrets, that Mod itself has access to the information before it is redacted. Settings that limit what the AI can read should be considered separately from the question of whether you can trust a Mod's code and its author.
Administrators can also set allowManagedModsOnly on the built-in control Mod so that Mods brought in by users are not loaded. Another option is to run a custom managed Mod first and have it deny file operations and process launches by other Mods.
In the public implementation of sec-default, you can see processing such as re-checking an operation when a user Mod changes a tool operation to an approval. This mechanism should not be interpreted as uniformly restricting every external operation by Mods, however.
When building a Mod for security purposes, you also need to consider how the Mod itself behaves when it fails. If an event function fails through an exception or timeout before calling the next step, by default that function is skipped and downstream processing continues. If you want the operation denied even on failure, you must explicitly return a denial within error handling. Simply installing a Mod meant to stop operations does not guarantee that it will always stop them when something goes wrong. Official behavior on failure
When deciding whether to adopt Mods, check the scope of access, not just features
Mods are enabled by default in Claude Code 2.1.287 and later. The environment variable CLAUDE_CODE_ENABLE_FUNCTION_HOOKS, used in the earlier trial phase, is ignored from this version onward. Even if you follow an old setup example and set its value to 0, you cannot disable Mods.
The screens a Mod can display also vary by environment. Mod screens can be shown in the terminal and in the Code tab of Claude Desktop, but Desktop's WSL sessions do not support plugins. In the VS Code extension's chat view, claude -p, and the Agent SDK, event functions work but Mod panels are not displayed. Before adopting Mods, you need to confirm that the features you need work in the environment you use. List of runtime environments
Before installation, you can use claude plugin validate to verify a Mod without running it and check which events it receives and which APIs it calls. This offers a clue as to whether the code accesses files, processes, or the network, but it is not a mechanism that certifies safety. Because the Mods API may change between releases, anyone building their own Mod should implement it against the type definitions generated by that version of Claude Code.
Being able to add the displays and confirmation steps they need lets developers extend their working environment without waiting for Anthropic to build them into the product. For companies, however, taking advantage of that freedom means weighing not only the feature they want to add but also which information the Mod behind it can read and which processes it can run.
The further Anthropic pursues its approach of keeping Claude Code's core small and adding needed features as Mods, the more the decisions about which features to adopt and how much permission to grant fall to the developers and organizations using Claude Code.