The finding reported by Akshay Chugh is specific but the implication reaches further: the Vercel plugin distributed for use with Claude Code requests permission to read user prompts. Not deployment outputs or build logs, but the actual text of conversations you have with Claude. The HackerNews thread attracted 267 points and over a hundred comments, which is the kind of engagement that happens when something touches a nerve people already had but hadn’t fully articulated.
Most developers installing a deployment helper are not thinking about their prompt text being collected. That gap between expectation and reality is the core of the problem.
How Claude Code’s Extension System Actually Works
Claude Code supports extensions through two main mechanisms: MCP (Model Context Protocol) servers and a hooks system. Both are configured in ~/.claude/settings.json or a project-level .claude/settings.json.
MCP servers run as separate processes and communicate with Claude Code over stdio or HTTP using JSON-RPC 2.0. They expose tools, resources, and prompt templates back to Claude. When you install an MCP server, Claude gains new callable capabilities. A deployment-focused plugin like Vercel’s would expose tools like vercel_deploy, vercel_list_deployments, or vercel_get_build_logs. Claude calls these tools when it determines they’re relevant to what you’re asking.
The hooks system is separate. Hooks are shell commands that fire in response to specific lifecycle events: PreToolUse, PostToolUse, Notification, and Stop. Each hook receives a JSON payload describing the event. For PreToolUse and PostToolUse, that payload includes the tool name and its input and output.
Neither mechanism, as designed by the MCP specification, should give a plugin direct access to the raw conversation prompt. MCP servers only see what Claude explicitly passes when calling their tools. Hooks only see tool-level events, not the full message history. So when a plugin ends up with access to prompt text, the interesting question is how that path opened up.
The Telemetry Path
The most likely mechanism is not a flaw in the MCP protocol itself but in how plugin authors instrument their code. Telemetry in developer tools is standard practice. Any well-run product team wants to know which commands are called, how often, what errors occur, and what context surrounded those calls. The problem is that in an AI coding tool, the “context surrounding a tool call” is often the prompt that triggered it.
When Claude calls a tool like vercel_deploy, the MCP server receives the structured arguments: project name, environment, branch. But if the plugin is also capturing the broader invocation context to understand user intent, or if Claude Code passes additional context fields along with tool calls, then prompt fragments start appearing in telemetry payloads.
The MCP specification defines a capability and permission negotiation model between clients and servers. Servers declare what capabilities they need; clients decide what to grant. Whether those boundaries hold under real implementation pressure, and whether users are clearly informed about what each plugin can observe, is exactly what empirical research like this surfaces.
There is also a subtler path: hooks. A plugin that ships with a configured PreToolUse hook receives JSON payloads for every tool invocation, including invocations of Claude’s built-in tools. Depending on how much context Claude Code includes in those payloads, a hook could capture significant information about conversation state.
Why Prompt Data Is a Different Category of Sensitive
The reason this matters more for AI coding tools than for a standard IDE extension is what developers put in prompts. When you ask Claude to help debug something or review a design, you frequently include:
- Proprietary source code, often unredacted
- Configuration files, sometimes with environment variable names or structures
- Internal API shapes and database schemas
- Business logic descriptions written in plain English
- Occasionally, accidentally, actual credentials or tokens pasted from a terminal
A deployment-focused prompt might read: “Deploy the main branch to production. Here’s the current env setup for context: [pastes from .env.example or a config template].” That is not a contrived scenario. It happens routinely when developers are context-switching fast and trust the tool they’re working in.
If a plugin captures that prompt for telemetry, it has extracted sensitive business context that was never intended to leave the machine. Traditional IDE telemetry collects command usage patterns. Code telemetry, at its worst, might capture snippets that the developer explicitly opened. Prompt telemetry is different: it captures raw, unfiltered developer intent, written without any of the filtering that comes from composing a commit message or opening a specific file.
This is not a hypothetical risk. It is the documented behavior of at least one plugin in active use.
The VS Code Parallel
This pattern has a clear historical precedent in the VS Code extension ecosystem. VS Code extensions run with broad Node.js process permissions by default, and for years the extension marketplace had limited vetting for what extensions actually did with their network access. Security researchers documented extensions performing unexpected outbound requests, some collecting clipboard contents and editor telemetry far beyond what their stated purpose required.
The VS Code team’s response evolved over years: better marketplace review processes, the introduction of extension permission declarations, and ongoing work on a more restricted extension host model. It took multiple documented incidents and sustained community pressure to move the needle.
Claude Code is earlier in that maturity curve. The MCP protocol is well-designed at the protocol layer, the JSON-RPC foundation is solid, and having a standardized protocol that other clients like Claude Desktop and third-party agents also implement creates real interoperability. But standardization also means a uniform surface for the same categories of problems. The plugin ecosystem is growing quickly, with hundreds of community-built MCP servers for databases, APIs, file systems, and developer services. Each one runs with whatever data access Claude Code grants it, and users currently have limited visibility into what that is.
Auditing What You Have Installed
If you use Claude Code with MCP servers, a few concrete steps are worth taking now.
First, open ~/.claude/settings.json and list every entry under mcpServers. For each one, look at its source. If it is open source, read the tool handler implementations, particularly any code that runs after a tool is called. Look for outbound HTTP requests that are not clearly tied to the tool’s stated function.
# On macOS/Linux, watch network activity from MCP server processes
lsof -i -n -P | grep -i mcpSecond, check for hooks configuration in the same file. Any hook that sends data to an external endpoint warrants scrutiny. A PostToolUse hook that pipes its payload to an external server has access to every tool call Claude makes in your sessions.
Third, consider project-level isolation. Claude Code supports project-level .claude/settings.json that can override or restrict which MCP servers are active. A deployment plugin does not need to be active when you are working on a client engagement with strict data handling requirements. Limiting plugins to the contexts where they are needed is a straightforward risk reduction.
What Needs to Change at the Platform Level
The individual developer mitigations above are useful but they are not a solution. Asking users to manually audit plugin network behavior is how the VS Code ecosystem operated for years before better tooling existed. The platform needs to close this gap.
At minimum, Claude Code should surface to users what data categories each installed MCP server can observe. A deployment plugin that only needs to make API calls to Vercel’s infrastructure does not need access to conversation context, and the permission model should make that distinction explicit and enforceable.
The MCP specification has an authorization framework for server-to-server authentication, covering how clients authenticate to servers using OAuth flows. What it does not yet fully specify is per-capability permissions for what a server can observe about conversation context. That is a meaningful gap in the current version of the protocol, and the Vercel finding is a concrete reason to close it.
On the telemetry side, plugins that collect usage data should be required to declare what they collect in a structured, machine-readable way, similar to how mobile app stores now require privacy nutrition labels. Whether a developer decides to use a plugin that collects prompt data is a legitimate choice; making that choice without the information is not.
The Vercel finding is useful precisely because it is specific and documented rather than theoretical. It makes a real gap visible. The appropriate response from the ecosystem is not to treat this as an isolated misbehaving plugin but as evidence that the permission and transparency infrastructure around AI coding tool extensions needs to develop faster than the plugin ecosystem is growing.