Claude Code becomes more malleable
Anthropic has introduced mods for Claude Code, giving developers a way to change the coding agent’s behaviour with small TypeScript functions. The company’s 1 October announcement says a mod can rewrite a prompt, adjust a tool call, alter a permission decision or replace part of the interface. Mods are distributed inside plugins and work in the Claude Code command-line interface and desktop app. This is a meaningful expansion of the product’s customisation surface: instead of only adding instructions around an agent, a developer can now intervene in events as the agent runs.
There is a corresponding trust boundary. Anthropic states that mods are not sandboxed and have the same access to a machine as Claude Code itself. That makes a mod closer to installed executable code than to a harmless prompt template. Anyone considering a third-party mod should treat its author, update path and requested behaviour as carefully as they would an editor extension or build tool.
What a mod can intercept
Claude Code emits events when it performs actions, including calling tools, requesting permission and drawing interface elements. A mod attaches to one of those events and can run before it, after it, in place of it or around it. Anthropic lists several concrete applications: changing a prompt before it reaches the model, blocking or retrying a tool call, approving or denying a permission request, and redacting secrets from tool output before Claude reads it. Mods can also add buttons or inputs to the terminal and desktop interfaces.
Those examples show why the launch matters to both individual developers and engineering teams. A team could make a coding session display its continuous-integration status, or require an additional check before an agent touches production configuration. A developer could customise a repetitive review flow without waiting for a built-in product feature. The extension point is broad enough, however, that a careless mod could also weaken a safety check or transform a tool request in a way its user did not expect.
Multiple mods can act on the same event. According to Anthropic, they run in load order, with the first-loaded mod seeing the event first and its resulting output last. The sequence is important when teams combine a security policy mod, a workflow mod and a user-interface mod. An administrator should test the combined behaviour, not assume that each component’s behaviour in isolation predicts the final result.
Beyond hooks and into replaceable features
Claude Code already offered hooks for certain workflow customisations. Anthropic says hooks cannot rewrite events, render new interface elements or replace built-in features. Mods are designed to cover those gaps. The company has also begun shipping some built-in functionality as mods: its existing /diff feature is one example, which users can turn off or replace through the plugin interface. Anthropic intends to move more features in that direction over time.
That design has a practical advantage. Teams with different review habits can tailor the same underlying agent to their own process, rather than maintaining separate wrappers around it. It also creates an operational responsibility: when a built-in feature becomes replaceable, an organisation should know which implementation is active, who supplied it and how it is updated. A replacement may look familiar in the interface while behaving differently under the hood.
Enterprise controls are part of the release
Anthropic says mods use existing plugin controls. Administrators can allow or block plugin marketplaces, while organisations using managed settings can push configuration to machines. On Team and Enterprise plans, and on machines with managed settings, a built-in security mod called sec-default loads first. Its purpose is to stop user-installed mods from taking risky actions, such as overriding permission-denial rules. Administrators may load their own mods first, but Anthropic advises them to include sec-default if they do.
These controls should not be mistaken for sandboxing. The company explicitly warns that mods themselves run with Claude Code’s machine access. The administrative layer can constrain certain behaviour, but the safer deployment pattern is still to review mod code and provenance, restrict approved distribution channels and trial changes in a non-sensitive environment. This is especially relevant for a mod that handles prompts, tool results or secrets: those are precisely the parts of a coding session where an unexpected transformation can be consequential.
What changes for developers
Mods are available now in the Claude Code CLI and desktop app. Anthropic says users can install plugins containing mods from the Claude directory or through the /plugin command. Developers can write a mod themselves, ask Claude Code to create one, and package it in a plugin for sharing. The company has published a getting-started guide and documentation alongside the announcement.
The immediate value is control over local workflows rather than a new model capability. A mod does not make Claude inherently better at reasoning or coding. It can, however, shape the information the agent receives, the actions it is permitted to take and the way a person reviews its work. For teams already building internal coding-agent practices, that is a significant lever. The question to answer before adopting a mod is not just what it adds, but which event it intercepts, what authority it inherits and how its behaviour is audited.
Anthropic’s announcement establishes the availability and mechanics of the feature; it does not demonstrate that every third-party mod will be safe or useful. The sensible next step for organisations is a small, inspectable pilot: choose one workflow, identify the desired event changes, test interactions with existing permissions and keep a clear rollback path. That approach lets teams benefit from Claude Code’s more flexible architecture without treating arbitrary plugin code as trusted by default.