Canonical: https://botbento.com/blog/claude-code-mods-unsandboxed-what-to-check/ Format: Markdown representation of the public HTML page. [Home](/) / [Blog](/blog/) FIELD NOTES / 5 MIN READ # Claude Code Mods Run Unsandboxed With Your Permissions. Check This First. Claude Code added 'mods' on October 1, 2026: in-process plugins that can redraw the interface, intercept prompts, and answer tool calls. Anthropic's own docs say mods run with the user's permissions and are not sandboxed, even when Claude's Bash sandbox is on. This piece lays out exactly what to check before you let one run, and what a team admin can and can't lock down. By BotBento Editorial · Published 2026-10-21 · Updated 2026-10-21 AI-assisted editorial: researched and drafted with AI using the primary sources linked below. Examples are illustrative; they are not measured product results. [Editorial policy](/editorial/). ## In this article - [What a mod actually is](#what-a-mod-actually-is) - [Why 'runs with your permissions' is the whole story](#the-permission-gap) - [Worked example: checking a mod before it runs](#worked-example) - [The decision: what to check before you install one](#decision-checklist)[Read as Markdown ](/text/blog/claude-code-mods-unsandboxed-what-to-check/index.md) ## Key takeaways - A mod runs inside Claude Code with your full account permissions; turning on Claude Code's sandbox only isolates Bash commands Claude runs, not a process a mod starts. - Run claude plugin validate on a mod's directory before installing it; the calls: and hooks: lines show what it reads, writes, and intercepts without running any code. - Deny rules and managed PreToolUse hooks only resist a mod's tool-call approvals when the built-in sec-default guard is loaded, which happens only under managed settings or a Team/Enterprise login. ## What a mod actually is A mod is a Claude Code plugin made of JavaScript or TypeScript event handlers that run inside the Claude Code process itself. A hooks module registers functions that fire on events like a tool call, a submitted prompt, or part of the screen being drawn, and each handler can watch the event, change it, or take it over entirely. That's a different category from a settings hook, which only runs a shell command or HTTP request you configure in settings.json. A mod sits inside the engine, not beside it. Anthropic shipped mods on by default starting in Claude Code v2.1.287 for the terminal and v2.1.286 for the Desktop app's Code tab. Anthropic ships a few sample mods itself in a playground repository: one draws a context-window forecast above the prompt, another holds a risky shell command like rm -rf and shows what it would change before you approve it, and a third lets you replay the file edits from the last turn. Those samples show the range: a mod can be a cosmetic status line or something that intercepts and decides on tool calls. Sources: [Mods overview - Claude Code Docs](https://code.claude.com/docs/en/plugins/mods/overview). ## Why 'runs with your permissions' is the whole story Anthropic's documentation is direct about what a mod can reach: it can read and write files anywhere your user account can, start programs, make network requests, read environment variables and settings files including any API key stored in them, see every prompt and tool call, and approve a tool call before you're asked. None of that requires a vulnerability. It's the normal operating mode of a mod, because a mod is code that runs with your permissions, inside Claude Code. The detail that trips people up is sandboxing. Claude Code's security docs describe a sandboxed Bash tool that isolates the commands Claude runs, with filesystem and network boundaries you configure. That sandbox does not extend to a mod. The mods documentation says it plainly: mods aren't sandboxed, and if you turn on sandboxing, the sandbox isolates the Bash commands Claude runs, while a process that a mod starts runs outside it. Turning on your sandbox setting gives you no guarantee at all against a mod's own file reads, network calls, or spawned processes. Deny rules have a similar gap. A rule that tells Claude never to read your .env file protects Claude's own tool calls. It does nothing to stop a mod from reading that file directly through its own file-system access, because that read never goes through Claude's tool-call path at all. The one thing a mod cannot touch is the permission prompt itself: a mod can restyle much of Claude Code's interface, but not the dialog that asks you to allow an action. Sources: [Mods overview - Claude Code Docs](https://code.claude.com/docs/en/plugins/mods/overview), [Security - Claude Code Docs](https://code.claude.com/docs/en/security). ## Worked example: checking a mod before it runs Say you find a community mod on GitHub called cost-tracker, advertised as a status line that totals your API spend above the prompt. Before installing it from a marketplace with /plugin install cost-tracker@some-marketplace, clone the repository and run claude plugin validate ./cost-tracker from your shell. This reads the plugin's manifest and hooks module without executing it, and reports the events it handles and the mods API calls it makes. If the output's calls: line lists only usage.read and ui.render, that matches the advertised behavior: it reads usage data and draws a status line. Now suppose the same validate output also lists fs.read, process.run, and net.fetch, and the events it handles include tool.call and tool.check. That combination means the mod can see and potentially answer or approve tool calls on your behalf, read arbitrary files, start processes, and send data over the network, none of which a cost display needs. That mismatch between advertised purpose and actual calls is the signal to stop before installing, not after. This is also where the built-in guard matters, but only if you're on a managed machine or a Team/Enterprise login. Claude Code loads a built-in mod named sec-default@builtin ahead of every mod a user installs, when the machine has managed settings or the session's credential is a Team or Enterprise login. That guard keeps a user's mod from overriding deny rules and managed PreToolUse hooks. On a personal machine with a Pro or Max subscription and no managed settings, that guard never loads, and a mod's approval can get a tool call past an ask rule or a PreToolUse hook that would otherwise have stopped it. Sources: [Mods overview - Claude Code Docs](https://code.claude.com/docs/en/plugins/mods/overview), [Mods reference - Claude Code Docs](https://code.claude.com/docs/en/plugins/mods/reference). ## The decision: what to check before you install one For a solo builder or small team running Claude Code without managed settings, treat every mod as code you're about to run with full account access, because that's what it is. Before installing: run claude plugin validate on the plugin directory and read the calls: and hooks: lines; reject anything whose declared calls go beyond its stated purpose; prefer mods from Anthropic's own sample repository or a marketplace you already trust over an unaudited GitHub link; and remember that your sandbox setting and your deny rules won't catch a mod's own file or network access, only Claude's tool calls. For a team, the only durable control is managed settings, because the sec-default guard and the allowManagedModsOnly option both depend on it. An administrator can set allowManagedModsOnly to true under pluginConfigs for cc-plugin-sec-default@builtin to block every mod a user brings, restrict which marketplaces are reachable with a marketplace allowlist, and install an organization's own policy mod ahead of user mods through prependPlugins. Without managed settings, a team is relying on each developer to run claude plugin validate themselves, which doesn't scale past a handful of people. If you're building a bot or routine around Claude Code and considering a mod for it, ask one question before anything else: does this task actually need a mod, or would a settings hook or a skill do it with a narrower footprint? A settings hook runs a shell command you configure and can't rewrite the model's session the way a mod can; a skill only adds instructions and tools Claude already asks permission for. Reach for a mod only when you need to redraw the interface, intercept a request before it reaches the model, or answer a tool call without running it. For anything else, the lower-reach option is the safer default. Sources: [Mods overview - Claude Code Docs](https://code.claude.com/docs/en/plugins/mods/overview), [Manage mods for your organization - Claude Code Docs](https://code.claude.com/docs/en/plugins/mods/admin). ## Primary sources Sources checked 2026-10-21. Standards and product documentation can change; follow the linked version when implementing. - [Mods overview - Claude Code Docs](https://code.claude.com/docs/en/plugins/mods/overview) — Anthropic - [Manage mods for your organization - Claude Code Docs](https://code.claude.com/docs/en/plugins/mods/admin) — Anthropic - [Mods reference - Claude Code Docs](https://code.claude.com/docs/en/plugins/mods/reference) — Anthropic - [Security - Claude Code Docs](https://code.claude.com/docs/en/security) — Anthropic BotBento is in development. [Suggest a correction](/contact/).