Claude Code mods are plugins that run code inside Claude Code with the user's own access, and they're on by default. Team and Enterprise admins get a built-in guard called sec-default plus managed settings to restrict them. The guard covers less than the name suggests, so the decision about which mods run on your developers' machines is yours whether you make it or not. For the wider picture, see AI in the engineering workflow: tools, permissions and policy.
What a mod is, and why it isn't a skill or an MCP server
Anthropic's October 1 announcement says mods ship inside plugins, so you install and share them like any plugin, in the CLI and the desktop app. A mod can rewrite a prompt, add new UI, replace a built-in feature, or add entirely new functionality. The mods overview puts it in one line: a mod is a plugin that changes how Claude Code looks and behaves.
A skill gives Claude instructions and an MCP server gives it tools. A mod runs inside Claude Code and can change prompts, tool calls and what the interface draws. Mods are on by default from Claude Code v2.1.287 in the terminal, and in the desktop app from v2.1.286.
What a mod can reach
The overview is blunt: a mod is code that runs with your permissions. It can read and write your files, start processes, and make network requests. It can read environment variables and settings files, including API keys. It sees every prompt and tool call, can rewrite either, and can approve a tool call before the user is asked. It can also spend the user's plan usage or API key by calling a model.
The docs also say mods aren't sandboxed. With sandboxing on, the sandbox isolates the Bash commands Claude runs, and a process a mod starts runs outside it. Anthropic ships three sample mods (token-weather, blast-radius and replay-theater) in a playground repository "as they are, without support."
What sec-default guards, and what it doesn't
The admin page describes a built-in mod, sec-default@builtin, that loads ahead of every mod a user installs. Users can't turn it off. It loads on a Team or Enterprise plan or on any machine with managed settings. With API key, Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry auth, it loads only where managed settings exist.
What it protects is specific. A user's mod can't change what your managed hooks receive or decide, the system prompt, your managed CLAUDE.md and other managed instructions, what any mod reads as settings, or the tools and descriptions of your managed MCP servers. Deny rules win too, unless someone sets allowModsToOverrideDenyRules to true.
Then the page lists what it allows: everything else. Files, processes, network, rewriting tool calls, approving a call that would otherwise prompt. The gaps matter more than the guard:
- With
Read(.env)denied, a mod can still read that file with$.fs.read, or start a program that does. - In auto mode, a call the mod approves runs without a classifier check, so a policy that relies on auto mode's classifier has a gap. Pinning Claude Code's managed settings from the admin console covers where to set the policy.
- The network policy covers
$.http.fetch, not a program the mod starts with$.process.run.
The page's own summary: none of these controls sandboxes a mod.
The policies an admin can choose
The admin page's policy table reduces to five choices. The trade-off column is our reading of the docs, not Anthropic's.
| Goal | Setting | Trade-off |
|---|---|---|
| No installed mods, hooks untouched | allowManagedModsOnly guard option, no mods of your own | Doesn't stop the plugin installing. Its skills and MCP servers still load. |
| No mods and no hooks, managed ones included | disableAllHooks set to true | Your own managed hooks stop too. |
| Only org mods | Guard option plus mods you install yourself | Needs device management to put your mods' marketplace directory on every machine; the admin console alone can't deliver it. |
| Any mod from approved marketplaces | Marketplace restrictions plus disableSideloadFlags set to true | Needs both. The allowlist alone leaves --plugin-dir open. |
| Any mod, checked by your own mod | Your mod listed with sec-default@builtin in prependPlugins | By default your check fails open if it throws or times out; add a .catch handler to fail closed. |
With allowManagedModsOnly on, no mod a user brings loads: not an installed plugin, not --plugin-dir, and not a mod Claude wrote during a session. Users' settings hooks, status lines and /goal keep working, and built-in mods keep running. Users can't undo it, because the guard reads the option from managed settings only. It also fails closed: if the guard can't read managed settings, it refuses every user mod at load.
How to roll out a mod policy
The plugins org page covers delivery. Set the keys as JSON in managed settings (file or MDM, or the admin console where your plan supports it, under Organization settings > Claude Code > Managed settings with the Owner role). One limit to plan around: server-managed settings deliver one configuration per organization, so you can't target a group.
1. Inventory what runs today
Run /plugin on a few machines to see what's installed. For the org-wide view, claude_code.plugin_installed records each install and claude_code.plugin_loaded records each enabled plugin at session start in OpenTelemetry. Third-party names are redacted unless OTEL_LOG_TOOL_DETAILS=1. On the Enterprise plan, GET /v1/organizations/analytics/plugins returns per-plugin, per-day install and invocation counts.
2. Review a candidate mod before approving it
Run claude plugin validate ./some-mod. It prints hooks: and calls: lines, for example $.fs.read, $.http.fetch. Read the calls like a permissions prompt. $.process.run and $.process.spawn start programs as the user, $.env.get reads environment variables and settings that can hold API keys, and $.model.complete uses the user's plan or API key.
3. Restrict marketplaces
strictKnownMarketplaces is an allowlist of marketplace sources, and an empty list blocks every source, the official marketplace included. It doesn't block --plugin-dir. Set disableSideloadFlags to true and Claude Code rejects --plugin-dir, --plugin-url, --agents, the Agent SDK plugins option, and non-SDK --mcp-config at startup. The docs point to the marketplace keys, not allowManagedModsOnly, for stopping a plugin that contains a mod from installing. Plugins in Anthropic's public directory go through an automated scan and review, and our piece on what the plugin directory scan checks explains it. That article doesn't cover mod code, so review a mod yourself with claude plugin validate.
4. Decide the mods policy
To allow only your own mods, set the guard option and install your mods so they count as yours. For illustration only, not part of this rollout:
{
"pluginConfigs": {
"cc-plugin-sec-default@builtin": {
"options": {
"allowManagedModsOnly": true
}
}
}
}5. Verify on a test machine
Start claude --plugin-dir ./first-mod. The mod's hooks shouldn't run, and the transcript and debug log should carry the guard's message naming the mod and allowManagedModsOnly. claude --debug shows the refusal line: refused by cc-plugin-sec-default: mods are limited to your organization's by policy (allowManagedModsOnly). If you also set disableSideloadFlags, --plugin-dir exits earlier with a message starting --plugin-dir is disabled by your organization's managed settings (disableSideloadFlags). To see the guard's refusal, test with a mod installed from a marketplace instead.
What this means for your AI tooling policy
Judgment, not Anthropic's advice. Mods are on and unsandboxed by default, so skipping the decision is itself a decision: every developer can install code that runs with their keys and files. Our default stance would be a marketplace allowlist plus disableSideloadFlags, then allowManagedModsOnly until someone owns mod review. Write your own policy mod only if that person will maintain it. The docs say a policy hook that throws or times out fails open unless you add a .catch handler that refuses, a --safe-mode session runs without installed mods yours included, and three worker crashes unload every mod that isn't built in.
Compare it with the deny-first model in deny, ask and allow rules for Copilot agents: there, a local setting can't weaken an admin rule; here, deny rules and managed hooks hold for Claude's tool calls, but a mod's own file and process calls sit outside them. Once the policy is set, a plan for measuring AI coding tool payback tells you whether the tooling earns its place.
FAQ
Are Claude Code mods sandboxed?
No. Anthropic's docs say so on both the overview and admin pages. Sandboxing isolates the Bash commands Claude runs, but a process a mod starts runs outside it, and the guard adds no other restrictions.
Does sec-default protect me if I do nothing?
Partly. It loads on Team and Enterprise plans and on machines with managed settings, and it shields your managed hooks, system prompt, managed instructions and managed MCP tools. On API-key, Bedrock, Agent Platform or Foundry auth without managed settings it doesn't load at all. A user's mod can still read and write files, make network requests and approve tool calls with that user's permissions.
Does allowManagedModsOnly stop a plugin from installing?
No. It stops a user's mod from loading, but the plugin still installs, and its skills and MCP servers still load. To stop installation, use the marketplace keys such as strictKnownMarketplaces.
Do mods run in CI with claude -p?
Mod hooks run in claude -p and the Agent SDK, according to the overview's table of where mods run. Drawing in the interface happens only in the terminal and the Desktop app. Treat CI runners as in scope, and check that managed settings actually reach them. The guard loads only on a machine with managed settings or a Team or Enterprise sign-in.