Claude Code Mods Security: Researchers Flag In-Process Risks

What happened

Anthropic has opened Claude Code, its command-line coding agent, to mods: plugins that can change how the agent behaves, reshape its interface, and swap in custom features. The official @ClaudeDevs account announced the capability on October 1, 2026, and the changelog ties its arrival to version 2.1.287 of the tool.3 Mods are written in TypeScript, either by hand or by asking Claude to generate them, and they ship inside plugins installed through the /plugin command in the CLI or desktop app.3 Anthropic has already built several mods into the product. Two more, a skill for writing new mods and a side agent that monitors long sessions, appear in the documentation without a linked public repository.3

Within days, two security research teams, Dash Security and Pluto Research, published analyses arguing that the feature creates a new and largely unexamined attack surface.12

Why mods are different from hooks

The central concern is where mod code runs. Earlier extension points, such as shell hooks, run as separate processes and see only the JSON payload Claude Code passes them. Mods are loaded into Claude Code itself, persist for the whole session, can hold state, and reach privileged operations through an engine interface exposed as $.12 According to Dash, that interface spans tools, files, processes, prompts, session data, MCP connections, and the UI.1 Pluto describes the same interface as covering file reads, command execution, network access, and drawing interface elements.2

Dash frames this as a matter of position. A mod sits on the path between what the user intends, what the model decides, and what actually executes on the host.1 Because a malicious mod's logic runs inside the Claude Code process, Dash argues that endpoint security tools may be unable to tell the mod's actions apart from the legitimate agent's.1 Dash enumerated the available functions and singled out host control, meaning the ability to execute, read, and write, as the capability threat actors are most likely to abuse.1

Where the researchers diverge

The two reports agree on the risk but give different weight to Anthropic's safeguards. Pluto credits Anthropic with real containment measures. Mod code runs in a worker without ambient fetch, require, or import. A static scanner records which $ methods a mod references. A mod's origin and tier are attributed by the host and cannot be spoofed, and the tool-approval prompt cannot be rewritten by a mod.2

Pluto still identifies four trust gaps:

• silent access to secrets
• missing disclosure of capabilities before installation
• UI spoofing
• code that can change after it has been reviewed

The disclosure gap stands out. Claude Code knows what a mod is asking for, but users are not warned before installing it.2

Dash's account says less about the sandbox and more about what falls outside it. Its point is that once the $ interface grants a capability, whatever sandboxing exists does little to help defenders who are watching the endpoint.1

There is also a small version discrepancy. Dash says its enumeration reflects v2.1.277,1 while the public launch is tied to 2.1.287.3 This may mean Dash examined the feature before general release, or simply that the surface is changing quickly. Either way, the exact list of exposed functions should be treated as a moving target.

Why it matters

The pattern is familiar from browser extensions, IDE plugins, and package registries. A powerful extension model arrives, an ecosystem grows around it, and attackers follow the trust it creates. What changes here is the host. A coding agent typically has access to source code, credentials, terminals, and connected services through MCP. A mod that can quietly read secrets or spoof parts of the interface inherits that reach, and it does so in a process users and security tools already trust.

The ease of authorship adds to the problem. If a few lines of TypeScript, or a request to Claude, can produce a mod,3 then the volume of third-party mods could grow fast. That increases the odds that users install something they have not read. Pluto's finding that code can change after review weakens any one-time inspection.2

Our reading

The sandbox described by Pluto shows Anthropic did not ship mods carelessly. Blocking ambient network and module access and protecting the approval prompt are meaningful choices.2 But the researchers' combined findings point to a gap between what the platform knows and what it tells users. The capability scanner already produces a record of requested permissions. Showing that record before installation, pinning reviewed code, and giving security tooling a way to attribute actions to specific mods seem like the obvious next steps.

Until then, organizations using Claude Code should treat mods like any other privileged third-party code. That means vetting their source, limiting installation to trusted publishers, and assuming that endpoint monitoring alone may not catch a mod that misbehaves from inside the agent.