Claude Code Mods Arrive On by Default, Running Unsandboxed

What shipped

Anthropic has opened Claude Code to modification from the inside. With version 2.1.287 of the command-line tool, published on October 1, 2026, a new extension system called mods became available and was switched on by default 45. The official @ClaudeDevs account pitched it as a way to change how the agent behaves, customize its interface, and swap in your own features. According to that pitch, a mod can be written in a few lines of TypeScript, or Claude can build one for you 5.

Technically, a mod is a plugin made of JavaScript or TypeScript event handlers that execute inside Claude Code's own process. Those handlers can observe, rewrite, or completely take over a tool call, a submitted prompt, or a piece of the interface as it renders 4. Mods are packaged as plugins and installed from a marketplace using the plugin name, an @ sign, and the marketplace name 1. They can also be added with the /plugin command in the CLI or desktop app 5.

Anthropic also publishes sample mods in its claude-code-playground repository. They are offered as-is and without support. Developers can load one for a single session with the --plugin-dir flag before deciding to keep it 1.

The playground reading

One coverage thread treats the launch as a creative breakout. It traces the system to a GitHub release by Claude Code head Boris Cherny in mid-September, ahead of its formal changelog entry on October 1 2. Within roughly ten days, the community had produced pixel pets, mini-games, and a mod by developer jarrodwatts that runs Doom inside Claude Code 2. The strangest example cited is Storytime. It embeds a 260,000-parameter model that writes a short story in real time based on what Claude is doing 2.

That same account says Anthropic builds its own features on the mod system, naming the /diff panel and AGENTS.md support. It also says community mods are being shared on claudemods.ai, and it contrasts this openness with OpenAI's more closed approach 2. A separate report notes two more Anthropic-built mods in the documentation that have no linked public repository: a skill for writing new mods and a side agent that monitors long sessions 5. A community catalog reportedly lists 45 mods so far 4.

The security reading

The other thread is far less celebratory, and it draws on Anthropic's own language. The documentation states plainly that a mod runs with your permissions. It can read and write your files, start processes, and make network requests, so users should install mods only from authors and marketplaces they trust 1. Security-focused coverage stresses that mods are not sandboxed. In that reporting's description, a mod can read secrets, approve tool calls before the user is asked, and spawn processes outside the sandbox 4.

Another analysis lists the likely failure modes:

• prompt injection through system prompts or hook pipelines that a mod inserts
• silent data exfiltration through hook callbacks
• arbitrary shell execution from overridden tool definitions 3

The same analysis also names the legitimate payoff. Teams can encode their conventions, project-specific tool behavior, and custom permission rules directly into agent sessions without forking the tool 3. Its practical advice is to treat the next Claude Code upgrade as the trigger for setting up a mod review process 3.

For organizations, the main lever identified is a managed setting, allowManagedModsOnly, which limits sessions to administrator-approved mods 4.

Why the default matters

The sources broadly agree on the facts: the version number, the date, the in-process execution model, and the lack of a sandbox. They differ on emphasis. The enthusiast coverage foregrounds Doom and storytelling models. It mentions security and incentives only as lingering concerns 2. The security coverage treats the same capabilities as an attack surface 34.

Both readings are correct, and they describe the same feature. A hook that can redraw the UI or reshape a tool call is what makes a Doom mod possible. It is also what would let a malicious mod quietly approve a destructive command. What raises the stakes is the on-by-default posture. Any team that updated past 2.1.287 is already running a mod-capable agent, whether or not anyone decided to allow that 34.

This is not a new kind of risk. Editor extensions and package registries have long run third-party code with user privileges. The difference here is the position of the code. A mod sits between an autonomous agent and the shell, file system, and credentials that agent can already reach.

For individual tinkerers, the trust advice in the documentation may be enough. For companies, the sensible move is to treat mods like any other dependency with execution rights: enable the managed-only control, review what gets approved, and do not assume that a plugin found in a marketplace has been vetted.