Claude Code Mods Run Unsandboxed, Exposing Developer Secrets

What happened

Anthropic's Claude Code supports mods, or plugins, that extend what the coding agent can do. Their security model is drawing scrutiny. These mods are not sandboxed. They run inside the Claude Code process with the same permissions as the developer who installed them. That gives them direct access to secrets and the ability to approve the agent's own tool calls 1.

Independent testing by Pluto Security makes the risk concrete. Mods built on function hooks were able to read credentials and session history, then send that data to a server controlled by an attacker. The user saw no prompt at any point 2. The built-in inspector, claude plugin details, could also report that such a mod had "zero hooks." A developer using the official tool to vet a plugin could therefore be told it was inert while it was actively intercepting activity 2.

Dash.security added a separate finding. Because the mod code runs inside the Claude Code process, endpoint security tools see only a legitimate Claude process at work. They cannot tell malicious mod behavior apart from normal agent activity 2.

Why the in-process design matters

Both reports point to the same root cause: running mods in-process with the user's permissions 12. Many browser extension and IDE plugin ecosystems eventually moved toward isolation, explicit permission manifests, or separate processes, largely because of this class of problem. When a plugin shares a process and privilege level with its host, the host's trust becomes the plugin's trust.

For an AI coding agent, that inherited trust is unusually broad. Claude Code routinely touches source repositories, environment variables, API keys, and shell commands. Session history can contain pasted secrets, internal architecture details, or proprietary code. A mod that can read all of this and approve tool calls on the agent's behalf 1 is effectively a second operator inside the developer's environment, one the developer never directly supervises.

The two sources cover different layers of the problem. The first focuses on what mods can reach and where deny rules stop being effective, and it offers configuration guidance 1. Its framing suggests that permission controls exist but have limits once code is running in the same process. The second documents real exploitation and the failure of both Anthropic's own inspection tooling and third-party endpoint defenses 2. Together they describe a gap at every checkpoint: before installation (the inspector can mislead), at runtime (no prompt is shown), and after the fact (endpoint security sees nothing unusual).

The plan-tier gap

The most consequential detail may be about who is protected. Anthropic does ship a guard, referred to as sec-default. It loads only on Team or Enterprise plans, or when managed settings are configured 2. Individual developers, who are arguably the most likely to experiment with community mods and the least likely to have a security team reviewing their setup, are left without that safeguard by default 2.

This creates an awkward split. Organizations with centralized administration get a baseline defense. Solo developers and small teams carry the full risk of an unsandboxed plugin model. Many of those developers have access to production credentials or open-source package publishing rights. A compromise on their machines can spread well beyond them.

Reading the situation

The most reasonable reading is that Claude Code mods should be treated like arbitrary code execution, because functionally that is what they are. The headline concern is not one vulnerability that a patch can close. It is a design choice that puts plugins inside the trust boundary 12. Until Anthropic isolates mods or makes protective defaults universal rather than tied to plan tier, the burden falls on users.

For security teams evaluating AI coding agents, a few implications follow from the findings:

• Do not rely on the built-in inspector alone. Pluto Security showed it can understate what a mod does 2. Reviewing source code, or limiting mods to trusted publishers, is more defensible.
• Assume endpoint tools won't flag mod abuse. Dash.security's work suggests detection has to happen elsewhere, for example by monitoring network egress 2.
• Use managed settings where possible. Since sec-default activates under managed configurations 2, organizations should apply them, and individuals should understand they are running without it.
• Revisit deny rules with their limits in mind. Permission rules help, but they don't fully contain in-process code 1.

AI agents are gaining extension ecosystems quickly, and Claude Code's mod system shows how those ecosystems can repeat old plugin-security mistakes in a setting with much higher stakes. The fix the evidence points to is architectural isolation, not more warnings.