Claude Implementation
Claude Code Mods Just Shipped. For a Business, That's a Policy Decision.
On October 17, 2026, Anthropic shipped a new extensibility layer for Claude Code called Mods — third-party code that now runs inside Claude Code's own process, not alongside it. Anthropic's own documentation is unusually direct about what that means: a mod can read your files, see every prompt, and approve its own tool calls. For a business rolling Claude Code out past a handful of early adopters, that direct language is the implementation brief, not a footnote.
What actually shipped
Claude Code's Mods overview describes a mod as “a plugin that changes how Claude Code looks and behaves,” built from JavaScript or TypeScript event handlers that Claude Code calls directly when a tool runs, a prompt is submitted, or part of the interface is drawn. That is a different trust boundary than the extension points Claude Code already had. Settings hooks run an external script. Skills hand Claude more instructions to read. MCP servers run as a separate process and only get the tools they're given. A mod runs inside Claude Code itself, with the ability to watch an event, rewrite it, or take it over entirely before anything else sees it.
Alongside Mods, Anthropic opened claude-plugins-official, a first-party curated plugin directory split into Anthropic-maintained plugins and a vetted external-plugins section, and extended cloud sessions so a coding task keeps running on Anthropic's infrastructure after a developer closes their laptop. Mods are on by default starting in Claude Code v2.1.287 for the terminal and v2.1.286 for the Desktop app's Code tab — which means a business that has not touched its Claude Code settings already has this feature turned on for every developer who updates.
What the documentation says a mod can touch
This is the part worth reading in Anthropic's own words, because it is not vendor caution — it is a plain inventory. The Mods overview states that once a mod loads, it can:
- Act on the machine as the user — read and write any file the account can reach, start programs, make network requests
- Read secrets — environment variables and settings files, including an API key kept in either
- See and change the session — every prompt and tool call, which it can rewrite or submit as if the user had typed it
- Act without asking — approve a tool call before a permission prompt would otherwise appear
- Spend usage — call a model on the user's plan or API key
Anthropic's guidance follows directly from that list: “Install mods only from authors and marketplaces you trust.” Mods are not sandboxed — turning on Claude Code's sandboxing isolates the Bash commands Claude runs, but a process a mod starts runs outside it. That is a reasonable design for an individual developer who wrote their own mod. It is a different conversation for a business that just told a few hundred engineers to update Claude Code.
The default is on, with one built-in guard
Out of the box, a built-in mod named sec-default loads ahead of anything a user installs, but only on a machine with managed settings deployed, or when the user is signed in on a Team or Enterprise plan. The administrator documentation is explicit about the limits of that default: the guard protects what an organization already manages — its managed hooks, its system prompt, its managed MCP server configuration — and nothing else. “Everything else is allowed,” the docs state. A user's mod can still read and write files, start processes, make network requests, and approve its own tool calls, all with that user's access. Four mods ship built in — an AGENTS.md loader, the /diffpane, a telemetry mod, and a “you should know” side-agent that flags missed information — and their source is public in the Claude Code repository, so a security team can read exactly what the defaults do before deciding whether to change them.
The decision a rollout actually has to make
Anthropic's admin documentation lays out the policy spectrum as a short table, and it maps onto a real decision a business makes once, in managed settings, rather than one each developer makes for themselves:
No mods at all
Set allowManagedModsOnly on the built-in guard and deploy no mods of your own. No installed mod runs its hooks; a developer's existing settings-hooks, status line, and slash commands keep working.
Only mods the organization issues
Same allowManagedModsOnly setting, plus the organization's own mod installed and ordered ahead of everything else with prependPlugins. Developers get exactly the extensions the organization has reviewed and nothing a GitHub link installed.
Any mod from approved marketplaces
Keep a marketplace allowlist and set disableSideloadFlags, so a developer can install from a vetted catalog like claude-plugins-official but can't sideload an arbitrary plugin directory or URL.
Open, with an audit mod watching
Leave mods open to developers, but install an organization mod ahead of the rest that can refuse a mod calling a blocked method (Anthropic's own example refuses any mod that calls process.run) and log every tool call and file write for review.
None of these four is the “correct” one. A ten-person engineering team prototyping fast and a bank modernizing legacy systems with Claude Code land on different rows of that table — but both are making an active choice rather than inheriting the default silently.
Why this isn't a hypothetical at scale
The reason to treat this as an implementation decision now, rather than when something goes wrong, is the scale Claude Code is already running at. Anthropic's own case study on Barclays says the bank expects Claude Code adoption to reach 50% of its developer population by the end of 2026, rising to a majority of software engineers in 2027, as part of a broader effort to modernize legacy platforms. Anthropic's commercial leadership frames the engagement around the fact that “Barclays is rolling Claude out with strong security and oversight” — which is precisely the posture that a managed-settings mod policy, decided deliberately rather than left at its default, is built to support. A rollout at that size is not a context where “everything else is allowed” should be the final word on an entirely new code-execution surface.
Where Skoor fits
Skoor implements Claude — Anthropic's own apps, on a business's own devices — and writes the managed-settings policy that goes with it as part of that rollout, not as an afterthought. That includes which mods and plugin marketplaces a role may load, alongside the connector allowlists and role-scoped permission profiles that are already live in Skoor's solutions catalog. Each profile is versioned and scored on an ongoing basis against the policy it was deployed under, with drift caught inside a committed window and every action logged and attributable — the same discipline a new extension surface like Mods needs applied to it the day it ships, not months after adoption.
Learn More
Roll out Claude Code with the policy decided up front
Role-scoped permission profiles, connector and plugin allowlists, and ongoing drift scoring — written down before developers start installing anything.
See how Skoor implements Claude