Claude Code is adding a deeper customization layer called mods: TypeScript functions that can change prompts, tool behavior, permissions, and parts of the interface. The October 1 announcement says mods ship inside plugins, using the existing installation and sharing system.
The release supports the Claude Code CLI and desktop app. Developers can write a mod themselves or ask Claude Code to create, install, and hot reload one in their current session. That convenience comes with an important boundary: mods have the same access to the machine as Claude Code and are not sandboxed.
Events become customization points
Claude Code emits events when it performs actions such as calling a tool, requesting permission, or drawing an interface element. A mod can run before an event, after it, in its place, or around it.
Those positions allow changes that go beyond the earlier hooks. A mod can rewrite a prompt before the model sees it, block or retry a tool call, approve or deny a permission request, or redact secrets from tool output. It can also replace a rendered tool result or add buttons and inputs to the interface.
Multiple mods can target the same event. Their load order matters: the first one loaded sees the event first and its result last. Teams combining independently written mods therefore need to understand how their behavior composes, rather than assuming each customization operates in isolation.
Plugin controls remain part of the deployment
Admins can allow or block plugin marketplaces using existing controls. Team and Enterprise owners configure those policies in the admin console, while Claude API and third-party API administrators use managed settings on users' machines.
A built-in mod named sec-default loads first on Team and Enterprise plans and machines with managed settings. The announcement says it prevents user-installed mods from performing risky overrides, including overriding permission-deny rules. Administrators can supply their own first-loaded mods, but are told to include sec-default to retain its restrictions.
These controls do not change the publisher's warning that mods are unsandboxed code. A marketplace policy and an installed mod's actual behavior are different parts of the trust decision.
Practical extensions, with boundaries
The announcement gives examples such as showing CI/CD status beside the conversation, requiring confirmation before a command touches production configuration, and recording other mods' calls for auditing. These are possible applications, not evidence that a particular third-party implementation has been tested or provides complete protection.
Secret redaction is especially sensitive to where information enters the session. Research on secrets retained in active conversations examines later recovery of information users already disclosed. Redacting a tool result before the model reads it addresses an earlier point in that flow; it does not establish that secrets already in conversational context have been removed.
Some built-in functions are also moving into the mod system. The announcement identifies /diff as an example users can disable or replace through plugin controls, with more features planned. That opens room for narrower installations, but the future plan should not be confused with features already converted. Developers can inspect or replace that existing diff implementation through the plugin system.
For teams adopting mods, the concrete change is broader control over an agent's inputs, actions, and interface. The same breadth increases the importance of reviewing the code, its event position, and its interaction with managed permission rules before relying on it in a sensitive workflow.