Claude Code Mods Can Approve Permission Prompts. Treat Every Mod as Code With Agent Privileges

Anthropic shipped Claude Code Mods on 1 October 2026. A mod is a small TypeScript function that hooks into events inside Claude Code and runs before, after or instead of a built in step. Published examples show mods that rewrite a prompt before it reaches the model, block or retry a tool call, redact secrets from tool output, add buttons and panes to the interface, and replace built in features such as the diff view. Mods travel inside plugins, install through the /plugin command or the Claude directory, and work in both the CLI and the desktop app. Claude Code will also write a mod for you on request, install it and reload it in the same session.

Two details in the launch coverage matter more than the demos. First, a mod can approve or deny a permission request. That is the prompt a developer sees before the agent runs a shell command, edits a file outside the project or calls a network tool, and it is the last human checkpoint most teams rely on. Second, mods are not sandboxed. Anthropic states that they run with the same access to the machine as Claude Code itself and advises installing only mods from sources you trust. Put those together and a mod is not a theme or a settings file. It is executable code that sits inside the agent loop with the authority to say yes on your behalf.

We covered the plugin supply chain problem in our piece on Plugin4Shell and SHA pinning, and Mods raise the stakes. A malicious or careless plugin used to be limited to the tools, skills and hooks it declared. A plugin that carries a mod can quietly change what the model is told, auto approve the commands it wants, and redraw the interface so the developer never sees the prompt they would have refused. The same pattern applies to the agent skills declaration gap we described under the OWASP Agentic Skills Top 10: what a package says it does and what its code actually does are two different things, and only one of them is reviewed in a marketplace listing.

Anthropic has given administrators a lever. Team and enterprise settings can allow or block plugin marketplaces, organisations can deploy their own mods through managed settings, and there is a built in mod called sec-default that blocks risky behaviour such as a mod overriding permission deny rules. Mods stack in load order, and the guidance is to load sec-default first and include it in any managed configuration so those restrictions survive. If you run Claude Code under team or enterprise plans, that is the control to set this week, before developers start installing mods from community collections.

The self authored case needs its own rule. Because Claude Code can write and install a mod mid session, a prompt injection in a README, an issue or a fetched web page now has a plausible path to persistence: persuade the agent to create a helpful mod, and the change outlives the session that produced it. Treat any request to create or modify a mod the same way you treat a request to edit shell profiles or CI configuration. It should require explicit human approval, and in managed environments it should be blocked unless the mod comes from your own reviewed marketplace.

Map it to the frameworks you already report against. Under ISO 27001, Annex A 8.19 on installation of software on operational systems, 8.28 on secure coding, 8.32 on change management and 5.19 to 5.21 on supplier and ICT supply chain security all apply to a mod that runs on developer endpoints with agent privileges. For SOC 2, CC6.8 on preventing unauthorised software and CC8.1 on change management are the criteria an auditor will reach for. ISO 42001 adds Annex A controls on AI system operation and third party AI components, so record approved mods in your AI system inventory alongside the models and connectors they modify. If you track evidence in Vanta, Drata or Secureframe, add the managed settings file and the marketplace allowlist as artefacts, not just a policy statement.

The practical controls are short. Allow only your internal plugin marketplace plus a named list of vetted public ones, and pin plugins to a commit rather than a branch. Load sec-default first in managed settings and confirm that permission deny rules still fire with your full mod stack installed. Review mod source before approval with particular attention to any handler that touches permission requests, prompt rewriting or interface replacement, since those are the three places a mod can hide intent. Log which mods are active per developer so incident response can answer the question of what was in the loop when a bad command ran.

A short list for this week. Inventory who is on Claude Code and which plugins they already have, because existing plugins can gain mods in an update. Set the marketplace allowlist and sec-default in managed settings. Add a line to your AI acceptable use policy that says developers may not author or install mods that approve permission requests without security review. Then brief the team, because the launch demos are fun and adoption will be fast.

Our view is that Mods are a sensible extension point, and a loop detector or token meter is exactly the kind of thing engineering teams should be able to build. But a function that can approve permission prompts is, functionally, a second user at the keyboard. Govern it like one, give it a reviewed source and a pinned version, and do not let the convenience of an agent writing its own mods turn your last human checkpoint into a setting someone else controls.