The mod that is not a sandbox

On 1 October 2026 Anthropic introduced mods, small TypeScript functions that ship inside plugins and change how Claude Code behaves and what it draws. A mod hooks an event, such as a tool call, a submitted prompt, or a piece of the interface, and it can watch that event, rewrite it, or answer it. The launch post puts mods in the Claude Code CLI and the desktop app. It says they run with the same access to the machine as Claude Code itself, that they are not sandboxed, and that you should install them only from sources you trust. The same post says hooks can't rewrite events, draw new UI, or replace features, and that mods can. It says /diff is now a mod you can turn off or replace, and that more built-in features will move to mods over time. That move is a plan. The release is Claude Code v2.1.287, published the same day. The story for this desk is the trust model, not a theme for the terminal.

1. 01On 1 October 2026 Anthropic's launch post introduced mods as small TypeScript functions inside plugins. They run with the same access to the machine as Claude Code itself, they are not sandboxed, and they should be installed only from sources you trust. The post says they work in the Claude Code CLI and the desktop app. It says hooks can't rewrite events, draw new UI, or replace features, and that mods can. It says Anthropic plans to move more built-in features to mods over time, with /diff named as one that already has.Anthropic launch post, 1 Oct 2026
2. 02Mods require Claude Code v2.1.287 or later and are on by default. GitHub published release v2.1.287 on 1 October 2026 at 18:00 UTC. The release notes say plugins may now modify deeper behavior. The launch post, the overview, and those notes do not label mods as preview or as GA, and they do not name a plan tier required to use a mod.Mods overview; GitHub release v2.1.287, 1 Oct 2026
3. 03Once a mod loads, it can read and write files anywhere the user can, start programs, and make network requests. It can read environment variables and settings, including an API key kept in either. It can see every prompt and every tool call, rewrite a prompt or a tool call, submit a prompt as the user, and approve a tool call before the user is asked. If sandboxing is on, it isolates the Bash commands Claude runs. A process a mod starts runs outside that sandbox.Mods overview, Decide whether to trust a mod
4. 04The getting-started guide, published 1 October 2026, says the module runs in a sandbox of its own, with no DOM and no Node, so everything outside it goes through the $ API. A mod is a plugin: .claude-plugin/plugin.json, hooks/hooks.json with a modules entry, and a module that exports register(on, options). The overview says settings hooks, skills, and MCP servers still work. Its comparison table says a settings hook can change whether a tool call or prompt goes ahead, a tool call's arguments and result, and context added for Claude.Getting started, Addy Osmani, 1 Oct 2026; Mods overview; Mods reference
5. 05Hooks run, and what a mod draws appears, for claude in a terminal, including an editor's integrated terminal and the JetBrains plugin, and for the Code tab of the Desktop app, except elements the docs mark terminal-only. A WSL session in the Desktop app does not run hooks, because plugins are not available there. The VS Code extension's chat panel runs hooks and does not show what a mod draws. claude -p and the Agent SDK run hooks and do not draw. The 1 October launch post names the CLI and the desktop app.Mods overview, Where mods run; Anthropic launch post, 1 Oct 2026
6. 06The overview's built-in list includes cc-plugin-diff, which takes over /diff; cc-plugin-agents-md; cc-plugin-sec-default; and cc-plugin-telemetry. cc-plugin-you-should-know is disabled by default. It runs a side agent and, when it finds something worth knowing, shows a note above the prompt. The v2.1.287 notes say to turn it on with /plugin enable cc-plugin-you-should-know@builtin. The settings and flags that stop installed mods do not stop built-in mods.Mods overview, Mods built into Claude Code; GitHub release v2.1.287
7. 07sec-default (cc-plugin-sec-default, and sec-default@builtin in a prepend list) loads when the user is signed in on a Team or Enterprise plan, or on any machine with managed settings. Where it loads, a user's mod cannot approve a tool call that a deny rule refuses. The admin page says those deny rules, and a block from a PreToolUse hook in managed settings, apply to Claude's tool calls and not to the mod's own $.fs and $.process calls. With Read(.env) denied, a mod can still read that file with $.fs.read or start a program that does. The same page says none of these controls sandboxes a mod.Manage mods for your organization
8. 08Org control is managed settings, including allowManagedModsOnly, marketplace restrictions, disableSideloadFlags, and prependPlugins or appendPlugins. A plugin Claude Code copies from a GitHub, git, URL, or npm source counts as the user's, even when managed enabledPlugins turns it on. An organization's own mod has to be a marketplace directory on the machine, named by absolute path. Setting prependPlugins replaces the default: the page says to name sec-default@builtin in that list to keep the guard. claude plugin validate lists a mod's hooks and calls without running it. That check is not a sandbox.Manage mods for your organization; Mods overview

We assess, with high confidence, that the mechanism is the one Anthropic wrote down on 1 October. The headline is not a theme for the CLI. A mod is in-process code with the user's access: files, programs, network, environment and settings including an API key, every prompt and tool call, and the ability to rewrite them, submit a prompt as the user, or approve a tool call before the user is asked.

The word sandbox is doing two jobs. The getting-started guide's sandbox is a JavaScript host: no DOM, no Node, side effects through the $ API. The overview's sandbox, when it is on, isolates Bash commands Claude runs, and a process a mod starts runs outside it. claude plugin validate is a third thing, a static list of hooks and calls. The admin page says none of the listed controls sandboxes a mod. A mod you allow runs as the user.

sec-default does not close that gap. Where it loads, a user mod cannot approve a call that a deny rule refuses, and the deny rule still does not bind $.fs or $.process. Brief the admin example: Read(.env) denied, and the mod can still $.fs.read the file or start a program that reads it. Org control is managed settings, not a list of mod names. A plugin copied from GitHub, git, a URL, or npm still counts as the user's. An org-owned mod has to be a directory on the machine. A prependPlugins list that omits sec-default@builtin drops the guard. Hold one more split. The launch post says hooks can't rewrite events. The overview says a settings hook can still change whether a call proceeds, its arguments and result, and added context. The plan to move more built-ins onto mods is a plan. /diff has moved. Authors hook events.

• Installing a mod is installing code that runs as the user, including a path to environment variables and settings that can hold an API key.
• A deny rule on Read(.env) does not stop $.fs.read or a program the mod starts. Claude's Bash sandbox does not cover that process, and the no-DOM, no-Node host is not that sandbox either.
• Team and Enterprise, and any machine with managed settings, get sec-default only while it actually loads. A prependPlugins list that omits sec-default@builtin drops it.
• A plugin from GitHub, git, a URL, or npm remains the user's. An org-owned mod is a directory on the machine.
• The launch post names the CLI and the desktop app. VS Code chat runs hooks and does not draw. A WSL Desktop session runs no hooks.
• You should know is off by default, an opt-in side agent, not the product. claude plugin validate is a review step, not containment. Settings hooks, skills, and MCP still run.

If you install a mod this weekend, trust it the way you trust any program you run as yourself. Do not treat a permission deny rule, or Claude's Bash sandbox, as a sandbox around the mod: the admin docs say that with Read(.env) denied, a mod can still $.fs.read that file or start a program that reads it. Run claude plugin validate on the plugin directory and read the calls line before you load anything you have not already decided to trust. If you run Team or Enterprise, confirm cc-plugin-sec-default is actually loaded, and if managed settings set prependPlugins, confirm that list still names sec-default@builtin. A plugin copied from GitHub, git, a URL, or npm still counts as the user's.

• A sandbox that contains a process a mod starts, or deny rules that bind $.fs and $.process.
• A preview or GA label, or a plan-tier requirement, on mods.
• Drawn UI in the VS Code extension. The overview table says hooks run there and drawing does not.
• An organization install path for an org-owned mod that is not a directory on the machine.
• A revision that makes the launch line on hooks and the docs table on settings hooks say the same thing.
• A dated list of built-ins moving to mods, beyond the plan stated in the 1 October launch post.

• Anthropic launch post - 1 Oct 2026, claude.com/blog/claude-code-mods: CLI and desktop, same access, not sandboxed
• Mods overview - code.claude.com docs: what a mod can reach, where hooks and drawing run, built-ins, v2.1.287 on by default
• Manage mods for your organization - Admin docs: sec-default, deny rules vs $.fs and $.process, prependPlugins, org directory vs copied plugins
• Mods reference - code.claude.com docs, as of v2.1.287: plugin.json, hooks.json modules, register(on, options)
• GitHub release v2.1.287 - anthropics/claude-code, published 1 Oct 2026 18:00 UTC: Claude Mods, You should know opt-in
• Getting started with Claude Code mods - Addy Osmani, claude.dev, 1 Oct 2026: no DOM and no Node, side effects through the $ API