Claude Code Mods Ship Unsandboxed, On by Default

Claude Code Mods can rewrite prompts and approve tool calls with full machine access. Only Team and Enterprise accounts get a default guard.

Claude Code Mods went live by default around October 1, 2026, with no opt-out switch left standing. A mod is a plugin that can rewrite what Claude is told to do and approve its own tool calls before a permission prompt ever appears. It runs with the same access to the machine as Claude Code itself, and Anthropic's own documentation says plainly that it is not sandboxed. Only accounts signed in on a Team or Enterprise plan, or machines that already have managed settings pushed to them, get a protective default mod loaded ahead of it. Everyone else gets the capability with no built-in guard at all.

Sources: Anthropic, Mods overview, AI Weekly

A mod is a plugin made of JavaScript or TypeScript event handlers that Claude Code calls directly inside its own process, on events like a submitted prompt, a tool call, or a piece of the interface being drawn. Anthropic's own documentation is specific about what sets this apart from an ordinary settings hook: a settings hook runs an external script and can only allow, block, or log an event; a mod's handler runs inside the agent and can rewrite the event itself, including the prompt the model receives and the tool call it is about to make.

Sources: Anthropic, Mods overview

What shipped, and when

Anthropic's documentation puts the terminal-default switch precisely: "Mods are on by default. In the terminal, use Claude Code v2.1.287 or later," with the Desktop app's bundled copy picking up the same behavior from v2.1.286. The same page notes that an early-access opt-out, the CLAUDE_CODE_ENABLE_FUNCTION_HOOKS environment variable, stopped doing anything in v2.1.287 and later, so setting it to 0 no longer keeps mods off. AI Weekly's coverage, published October 2 and updated October 3, independently places the introduction of mods on October 1, 2026, which lines up with the version Anthropic names for the default-on terminal behavior.

Sources: Anthropic, Mods overview, AI Weekly

The feature is not a side door. Anthropic moved its own built-in features onto the same mod system: the /diff pane, AGENTS.md loading, and a new opt-in "you should know" watcher agent all ship as mods under the hood, listed next to anything a third party installs. Mods also back one of Claude Code's more consequential behaviors, approving or denying a tool call before the user ever sees a permission prompt, which is the exact capability this post is about.

Sources: Anthropic, Mods overview

Not sandboxed, in Anthropic's own words

Anthropic does not soften this claim. Its documentation states flatly, "Mods aren't sandboxed," and spells out exactly what that means once a mod loads: it can act on the machine as the user, reading and writing any file the account can reach, starting programs, and making network requests; it can read environment variables and settings files, including any API key stored in either; it can see and rewrite every prompt sent and every tool call Claude makes; and it can approve a tool call before the user is ever asked. Separately, it can also call a model on the user's own plan or API key for its own purposes, spending that usage without being asked either.

Sources: Anthropic, Mods overview

Third-party coverage summarized the same point in blunter terms. AI Weekly's write-up states that mods "run with the same access to your machine as Claude Code itself," and that they "aren't sandboxed, and you should only install mods from sources you trust." A separate explainer on the question, published October 3, answers it in two words: "No. Claude Code mods are not sandboxed," and notes that the Bash sandbox is a separate control that restricts shell commands but, in its own words, "does not isolate mod code." Anthropic's own documentation explains why: turning on sandboxing isolates the Bash commands Claude runs, but "a process that a mod starts runs outside it," because a mod's own code was never inside that boundary to begin with.

Sources: AI Weekly, MacMyths, Anthropic, Mods overview

The default guard exists, but most accounts never see it

Anthropic does ship a protective mod, sec-default, loaded ahead of anything a user installs. Its documentation describes exactly two conditions that make it load: the machine has managed settings deployed, or the user is signed in to Claude Code on a Team or Enterprise plan. A user authenticating with a bare API key, or through Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry, gets the guard only if that machine also happens to have managed settings pushed to it. An individual or free-tier account with no organization behind it gets none of this by default. That covers anyone running Claude Code on a personal project, as a solo contractor, or on a small team with no admin console pushing settings to their machine.

Sources: Anthropic, managing mods

Even where sec-default does load, its job is narrower than the name suggests. Anthropic's documentation is explicit that the guard only protects what an organization centrally manages: a user's mod still cannot touch managed hooks, the managed system prompt, or managed CLAUDE.md instructions. Everything else is left alone by design. The same page states it directly: "The guard adds no other restrictions. A user's mod can still read and write files, start processes, make network requests, rewrite tool calls and prompts, deny a tool call, approve one that would otherwise prompt, and draw in the interface, all with that user's permissions." AI Weekly's report describes the guard's purpose as preventing risky actions "like overriding permission denials," which matches Anthropic's own carve-out for deny rules specifically, not a general safety net over everything a mod can do.

Sources: Anthropic, managing mods, AI Weekly

Why a permission-approving mod is a different category of risk

A coding agent that makes a mistake writes bad code. Bad code is visible: it sits in a diff, a reviewer reads it, tests run against it, a merge gate can hold it. A mod that approves tool calls does not produce an artifact anyone reviews by habit. It changes what gets approved, silently, on every call it touches, and the only trace is a debug log almost nobody reads during a normal session. The two failure modes are not the same shape, and treating a permission-approving extension like just another dependency undersells what it can quietly change.

• A buggy mod can approve a tool call an ask rule would otherwise have stopped for review, every time that call pattern recurs, without the mod author intending anything malicious.
• A malicious mod can do the same thing on purpose. Because it runs inside the agent process rather than as a visible external script, it leaves no diff for a reviewer to catch.
• A mod can rewrite the prompt the model receives before the model ever reasons about the task, so the model itself may be working from instructions the user never typed.
• None of this requires defeating Claude Code's own safeguards. It only requires the account missing the one default guard Anthropic ships, and per Anthropic's own documentation, that guard is absent on any account that is not signed in on a Team or Enterprise plan and has no managed settings pushed to it.

Anthropic gives teams a way to make that check without running the mod: claude plugin validate reads a mod's source and prints the events it hooks and the API calls its code makes, things like fs.write, process.run, or http.fetch, without executing any of it. That is a real tool, and it is a better starting point than trusting a plugin description. But it is also opt-in work that has to happen before every install, on every machine, for every update, and nothing in the default configuration forces it to happen at all.

Sources: Anthropic, managing mods

The governance gap most teams have not closed

Plenty of engineering teams spent the past year hardening how they review AI-generated application code: a diff gets checked against a spec, a second pass looks for edge cases the first pass missed, a security-minded reviewer looks for what an attacker would try. That scrutiny almost never extends to the extensions and plugins layer of the coding tool producing that code in the first place. Here is the part most coverage of mods missed: a mod sits one level below the application code it helps write, with more machine access than that application code will ever have at runtime, and it typically goes through no review process at all before it starts approving the agent's own permission requests.

That asymmetry is the actual story here, more than any single mod being good or bad. Teams spent real effort teaching themselves to distrust AI-written application code by default and verify it independently. The same week that discipline was taking hold, the tool producing that code shipped an extension point that runs with full machine access, is not sandboxed, and ships with a default safety net that individual accounts don't get. Separately, this landed in almost the same week GitHub pushed in the opposite direction on Copilot: local sandboxing for Copilot CLI, the Copilot app, and VS Code agent sessions reached general availability on October 7, 2026, letting organizations require it and lock the policy so developers can't weaken it. One vendor tightened a boundary. Another shipped a new one with no boundary at all, in the same stretch of the calendar.

Sources: GitHub Changelog, Copilot local sandboxing GA

What this means in practice

Where TLM Forge fits, and where it does not

TLM Forge does not sandbox a coding agent's extensions and would not have stopped a mod from approving a tool call it should not have. That is Anthropic's layer to secure, not a merge-time governance tool's. What TLM Forge is built around is the narrower, structural point this whole story turns on: a check that reports success without anything independent confirming what it actually did is not a check, it is a claim. Before an agent writes code, TLM Forge requires a spec audit against an agreed plan. Once code exists, an independent reviewer reads the diff in fresh context rather than taking the agent's own summary on faith, a red-team pass specifically hunts for what looks handled but is not, and a convergence gate blocks the merge until every flagged issue hits zero, not until a self-report says the work is done. You can read the specifics of how it works. A mod that certifies itself as trustworthy is making exactly the kind of unverified claim that governance layer exists to refuse.