Claude Code 2.1.287, released October 1, 2026, turned on Mods by default: plugins whose code runs inside Claude Code and can change prompts, tool calls and permission decisions. Anthropic’s own documentation tells you to install them only from authors you trust. This checklist is the review to run before you do, for one developer or for a whole team.
Editorial note: Built from Anthropic’s Mods overview, events guide, reference and administrator guide at code.claude.com, as published for version 2.1.287 and read October 3, 2026. The feature is new and the documentation will change; check it against the version you run.
- 01Validate before you loadOne command lists every event a mod handles and every API call it makes, without running it.
- 02Every call needs a reasonA theme mod that reads environment variables or makes network requests has some explaining to do.
- 03The guard has gapsDeny rules stop a mod approving Claude’s tool calls, not its own file and process calls.
- 04Teams decide centrallyOne managed setting keeps users’ own mods from loading, and users cannot undo it.
01 — The riskWhat you are trusting
Most plugins add instructions or tools. A mod adds code that runs in the middle of every session. The Mods overview lists what a loaded mod can do. In short: act on your machine as you, read environment variables and settings files where API keys often live, see and rewrite every prompt and tool call, submit a prompt as if you typed it, approve a tool call before you are asked, and call a model on your plan.
Two limits sit around that. Mods are not sandboxed, and turning on Claude Code’s sandbox isolates the shell commands Claude runs, not a program a mod starts. And a mod can restyle most of the interface but not the permission prompt, so what a prompt shows you is still accurate. A mod can, though, decide a tool call before any prompt appears. For the full mechanism, see our explainer on what Mods are and the events they hook.
02 — Step 1Read the validate output
Clone the plugin and run claude plugin validate on its directory. Nothing runs. The output has a hooks: line listing the events the mod handles and a calls: line listing the API methods its code uses. Anthropic’s administrator guide explains why the list can be trusted: the mods API is the only way a mod reaches files, processes or the network, and Claude Code refuses to load a mod that uses the API in a way the command cannot read.
Four entries on the hooks line mean the mod is in the decision path, not just watching. Check each one against what the mod claims to do.
- tool.call: sees every tool call and can change it, refuse it or answer it so the tool never runs.
- tool.check: can approve or deny a call before the permission prompt appears.
- prompt.submit: sees and can rewrite every prompt.
- session.append: can rewrite each row of the conversation before it is stored.
03 — Step 2Question each call
The calls line is where a review earns its time. The administrator guide names the calls to look for. The third column is our test: the question the mod’s author should be able to answer in one sentence.
| Call | What it lets the mod do | Ask before installing |
|---|---|---|
| $.fs.read, $.fs.write | Read or write any file you can | Which paths, and why? |
| $.process.run, $.process.spawn | Start programs as you | Which program? It runs outside the sandbox and outside network policy. |
| $.http.fetch | Make network requests | To which host, carrying what data? |
| $.env.get, $.settings.read | Read environment variables and settings, where keys live | Check the env reads line. Does any named variable hold a secret? |
| $.env.set | Set a variable for Claude Code and every command and MCP server it starts later | Could the value change what those programs run, such as a path or proxy? |
| $.model.complete | Call a model on your plan or key | How often, and with what in the prompt? |
| $.prompt.submit, $.session.send | Submit a prompt as you, or message another session | Why does a mod need to speak for you? |
| $.mcp.call | Call a tool on a connected MCP server, under your permission rules | Which server and tool? |
Combinations matter more than single calls. A mod that reads environment variables and makes network requests has everything it needs to send a key somewhere. That does not make it malicious, but it moves the mod from a skim to a line-by-line read.
04 — Step 3Read the hooks themselves
Mods are written in JavaScript or TypeScript, so the review can read the source rather than guess. For any mod in the decision path, read three things.
- What it approves. If a tool.check hook returns allow, write down the exact calls it approves. In auto mode, the administrator guide notes, a call a mod approves runs without the classifier check.
- How it fails. The events guide says a hook that throws or times out before passing the event on is skipped, so a guard without a catch handler lets the held command run. A guard should attach a catch handler that denies.
- Where data goes. Follow every fetch, file write and spawned process back to the event data it carries.
Then pin what you reviewed. A mod is a plugin, so it updates like one, and an update is new code. The administrator guide points to the plugin update policy for deciding when a reviewed plugin can change.
Where the built-in guard loads, a user’s mod cannot approve a tool call that a deny rule refuses. But that covers Claude’s tool calls only. Anthropic’s example: with reading .env denied, a mod can still read the file through its own API or start a program that does. Deny rules do not limit what a mod does itself.
05 — Step 4Set the team controls
For a team, the review is only half the job. The other half is deciding which mods can load at all. The built-in guard loads first on any machine with managed settings and for anyone signed in on a Team or Enterprise plan. A developer using an API key, Amazon Bedrock, Google Cloud or Microsoft Foundry gets it only on a machine with managed settings. By default the guard protects what the organisation manages and allows everything else.
allowManagedModsOnly
Users’ own mods do not load. Their settings hooks and status lines keep working. Read from managed settings only.
disableSideloadFlags
Rejects --plugin-dir and --plugin-url at startup and stops mods Claude writes during a session from loading.
Marketplace allowlist
A mod is a plugin, so existing marketplace restrictions decide whether it can be installed at all.
allowModsToOverrideDenyRules
Lets a user’s mod approve calls a deny rule refuses. Off unless set. Leave it off.
Two warnings from the guide. The early-access environment variable that once gated Mods is now ignored, so setting it to zero keeps nothing off. And none of these settings sandboxes a mod you allow: it still runs with the user’s access to files, processes and the network. The lesson from the ClawHavoc plugin incident applies directly. An extension marketplace is a supply chain, and the controls belong in place before the first install, not after.
06 — Practical implicationsInstall, limit or refuse
The review ends in one of four outcomes. Write the outcome and the reason down, so the next person who asks about the same mod does not start again.
If your team builds its own mods instead, the same guide shows how to run an organisation’s mods ahead of the guard and use one as a policy check on the others. That is the right home for the protection described in our inference hooks and data loss prevention guide. Where a team wants this designed and reviewed rather than improvised, our AI transformation work covers agent permissions, extension review and the record that goes with them.
Set allowManagedModsOnly first, then review one mod at a time
On a team, switch users’ own mods off centrally, then admit mods one at a time after a validate run, a calls review and a read of any hook that approves or rewrites. On your own machine, run the same steps before the first install, not after the first surprise.