· 6 min read ·

Claude Code Has a Plugin Trust Problem, and the Vercel Case Makes It Concrete

Source: hackernews

A post by Akshay Chugh found something worth paying attention to: the official Vercel plugin for Claude Code appears to request access to read the prompts you’re sending to Claude. The Hacker News thread picked it up and reached 267 points, which is enough signal that this landed as more than a minor curiosity. Whether Vercel is actually exfiltrating your prompts or just collecting light usage telemetry is somewhat beside the point. The more interesting question is how this is even possible, and what it says about the trust model underneath Claude Code’s plugin ecosystem.

How Claude Code Plugins Actually Work

Claude Code uses the Model Context Protocol (MCP) as its extension mechanism. MCP defines a standard interface for external processes to expose tools, resources, and prompts to an AI system. When you install a plugin, you’re registering an MCP server, typically in .mcp.json at the project root or in ~/.claude/settings.json globally.

A minimal MCP server config looks like this:

{
  "mcpServers": {
    "vercel": {
      "command": "npx",
      "args": ["@vercel/mcp-adapter"],
      "env": {
        "VERCEL_TOKEN": "your-token"
      }
    }
  }
}

The server process runs alongside your Claude Code session and communicates over stdio or HTTP/SSE. Claude can call tools that the MCP server registers, and the server responds with results. That part is relatively well understood.

What gets less attention is the scope of what MCP servers can observe. Tool calls happen in the context of an active session. When Claude decides to invoke a tool, it sends the tool name and arguments. Depending on how the integration is built, the surrounding conversation context, or even the raw prompt text, can travel along with that call. The MCP spec does not inherently prevent servers from logging whatever they receive. The constraint on what a plugin can see is mostly a function of what Claude Code chooses to pass, and how the plugin chooses to handle it.

The Telemetry Surface

Vercel’s plugin is built around deployment and project management. Reasonable things for it to know: which project you’re in, what commands you ran, whether a deployment succeeded. These are the inputs needed to provide the feature and to measure how people use it.

Where it gets uncomfortable is when telemetry crosses into capturing the content of your prompts. Your prompts are not just logs of what commands you issued. They contain the reasoning behind what you’re building, references to business logic, names of internal systems, sometimes credentials or tokens pasted in accidentally. The context you give Claude to help it understand your codebase is often more sensitive than the output Claude produces.

If a plugin can read that context, it is in a position to learn things about your project that have nothing to do with deploying to Vercel. That is a different category of data access than capturing “user ran deploy command at 14:32.”

This is not unique to Vercel. Any MCP server running in your session is in a similar structural position. The Vercel case is notable because it is a well-funded, widely used company, which means many developers will have this plugin installed without much scrutiny. The concern is not that Vercel is necessarily malicious, it is that the architecture creates an exposure surface that most users have not thought about.

Historical Parallels

This pattern has played out before in adjacent ecosystems. VS Code extensions run with broad filesystem and network access by default. The extension permission model has improved over time, but there was a period where extensions could quietly phone home with usage data and nobody raised an eyebrow. The VS Code marketplace telemetry debate from the early years shows how long it took to establish norms even for something as obvious as opt-out telemetry.

The npm ecosystem has a longer and more uncomfortable history. Packages like event-stream demonstrated that supply chain position equals trust, and trust can be abused. The challenge with MCP plugins is that you’re not just granting a package access to run some code during a build step. You’re inviting a process into a live AI session where sensitive reasoning is happening in real time.

The browser extension model is the closest analogue. Extensions can request permissions to “read and change all your data on the websites you visit,” and users routinely click through. The permission dialog exists because someone decided that explicit consent, however poorly understood by most users, is better than no consent. Claude Code does not yet have an equivalent.

What a Better Permission Model Looks Like

The MCP spec itself is relatively new. Version 1.0 of the protocol was only published in late 2024, and Claude Code’s integration of it is still maturing. The tooling for auditing what plugins can see does not yet exist in any meaningful form.

A responsible extension ecosystem needs a few things that are currently absent:

Scoped tool invocation. When Claude calls a tool, the call should include only what the tool explicitly declared it needs. If a deployment tool declares it needs the project directory and deployment target, those should be the only values that travel in the tool call. Passing the surrounding conversation context should require an explicit declaration.

Transparent telemetry disclosure. If a plugin sends any data to an external server, that should be declared in the plugin manifest and visible before installation. This is table stakes for any extension ecosystem, and the absence of it here is a gap worth closing.

Opt-in session observation. There are legitimate reasons a plugin might benefit from observing more of the conversation, for example a plugin that learns your coding preferences over time. But that should be an opt-in capability with a clear user-facing acknowledgment, not a default behavior that ships without disclosure.

Local logging by default. Any data a plugin needs to improve its own quality should default to local storage. If Vercel wants aggregate telemetry on how developers use the deployment plugin, they can ask for it explicitly.

Anthropologic has published guidance on MCP security considerations, and the spec does address trust boundaries at a high level. But guidelines in a spec document are not the same as enforced constraints at the platform level.

The Deeper Issue for AI Tooling

Claude Code is designed around the premise that you give the AI significant context about your work. That is the feature. The more context Claude has, the more useful it is. You share partial code, internal API designs, architecture decisions, error messages from production systems. The value of the tool is proportional to how much you’re willing to share.

Plugin authors sit downstream of that sharing. The more useful Claude Code becomes, and the more developers integrate it deeply into their workflows, the more valuable that position becomes. A plugin with access to the session context of a developer working on a large codebase has access to something genuinely worth protecting.

This is not a reason to avoid plugins. It is a reason to expect that the platform shipping them take the permission model seriously. The Vercel case is useful precisely because Vercel is a reputable company with no obvious malicious intent. It surfaces the structural issue without requiring a bad actor. The same architecture exists for every MCP server you install, regardless of who built it.

For now, the practical advice is straightforward: treat every MCP plugin like you’d treat a browser extension with broad permissions. Read what it declares it does, check whether it makes outbound network calls, and prefer project-scoped installation in .mcp.json over global installation for plugins you’re evaluating. The ecosystem is early enough that user pressure actually shapes how these tools evolve.

Anthroponic will need to move faster on this than the browser extension model did. The stakes of ambient access to AI sessions are higher than the stakes of ambient access to tab data, and the developer community building on Claude Code is technical enough to notice when the trust model has gaps.

Was this interesting?