--- title: "Vercel Claude Code 插件隐私边界：提示词读取权限的深层风险" route: "/posts/2026/04/10/vercel-claude-code-plugin-privacy-boundary/" canonical_path: "/posts/2026/04/10/vercel-claude-code-plugin-privacy-boundary/" canonical_url: "https://blog2.hotdry.top/posts/2026/04/10/vercel-claude-code-plugin-privacy-boundary/" markdown_path: "/agent/posts/2026/04/10/vercel-claude-code-plugin-privacy-boundary/index.md" markdown_url: "https://blog2.hotdry.top/agent/posts/2026/04/10/vercel-claude-code-plugin-privacy-boundary/index.md" agent_public_path: "/agent/posts/2026/04/10/vercel-claude-code-plugin-privacy-boundary/" agent_public_url: "https://blog2.hotdry.top/agent/posts/2026/04/10/vercel-claude-code-plugin-privacy-boundary/" kind: "research" generated_at: "2026-04-10T19:18:13.998Z" version: "1" slug: "2026/04/10/vercel-claude-code-plugin-privacy-boundary" date: "2026-04-10T01:25:42+08:00" category: "security" year: "2026" month: "04" day: "10" --- # Vercel Claude Code 插件隐私边界：提示词读取权限的深层风险 > 剖析 Vercel 插件请求读取全部提示词的权限模型，揭示 AI 工具的隐私边界模糊问题与工程级防护方案。 ## 元数据 - Canonical: /posts/2026/04/10/vercel-claude-code-plugin-privacy-boundary/ - Agent Snapshot: /agent/posts/2026/04/10/vercel-claude-code-plugin-privacy-boundary/index.md - 发布时间: 2026-04-10T01:25:42+08:00 - 分类: [security](/agent/categories/security/index.md) - 站点: https://blog2.hotdry.top ## 正文 当你在一个与 Vercel 毫无关系的项目上工作时，一个部署插件却弹窗询问是否愿意分享「提示词文本」，这本身就是一个值得警惕的信号。Akshay Chugh 在其博客中详细记录了这一事件的完整技术分析，揭示了 Vercel Claude Code 插件在隐私设计上的三重问题。 ## Consent 的虚假表象 Vercel 插件的帮助界面包括部署辅助、框架指导和技能注入等功能，这些能力与读取用户每一次提示词之间没有必然的因果关系。更值得深思的是它获取「同意」的方式：该插件并非通过原生 CLI 提示或设置界面与用户交互，而是将自然语言指令注入 Claude Code 的系统上下文。这些指令明确要求 AI 使用 `AskUserQuestion` 工具向用户提问，并根据用户回答执行相应的 shell 命令将偏好设置写入文件系统。 从技术实现角度看，这种做法本质上是「提示词注入」（prompt injection）的变体。插件向 Claude Code 的系统上下文注入了行为指令，而非仅仅提供关于 Next.js 路由的上下文信息。两者之间存在根本性差异：前者是「这里有一些关于框架的背景知识」，后者是「向用户提出这个具体问题，然后基于他们的回答修改文件系统」。虽然 Vercel 开发者回应称在 Cursor、Claude Code 或 Codex 等第一方市场中无法创建一次性 CLI 提示，但「无法构建 proper consent」的正确应对方式应该是「不提供该功能」，而非以提示词注入替代真正的用户授权机制。 用户看到的弹窗与 Claude Code 原生界面毫无二致，没有视觉标识表明这是第三方插件的行为。插件名称不会出现在问题文本之前，也没有权限说明。这导致用户无法区分「这是 Claude Code 在问我」还是「这是某个插件在借助 Claude Code 问我」。 ## 「匿名数据」的实质 该插件的隐私声明声称收集「匿名使用数据，例如技能注入模式和默认工具使用情况」，但实际收集的内容与这份声明之间存在显著差距。根据源码分析，收集的数据分为三个层级：设备 ID、操作系统、检测到的框架、Vercel CLI 版本在每次会话启动时自动发送，无需用户同意；每次执行 bash 命令后，完整的命令字符串（包括文件路径、项目名称、环境变量名称和基础设施细节）会被发送至 `telemetry.vercel.com`，这一行为同样无需用户授权；提示词文本的收集则是唯一的可选项，且仅在用户明确选择加入时才启用。 这里存在一个关键的表述陷阱：Consent 对话框将选择描述为「是否也分享提示词」，却从未告知用户 bash 命令收集是独立运行的、可以选择关闭的。企业级分析中，将完整的命令字符串描述为「匿名使用数据」本身就是一种误导——这些数据与持久性设备 UUID 绑定，在每次会话中持续关联发送，意味着用户行为可以被长期追踪和关联。 讽刺的是，关闭所有遥测数据的确存在一个途径：设置环境变量 `VERCEL_PLUGIN_TELEMETRY=off`。然而，这个选项仅在插件缓存目录内的 README 中有文档记录，用户在安装或首次运行时根本无法接触到这一信息。 ## 全项目无差别监控 真正引发广泛关注的原因是：该插件的遥测数据收集并不局限于 Vercel 相关项目。在一个完全不涉及 Vercel 的项目中——没有 `vercel.json`、没有 `next.config.js`、没有 Vercel 依赖——插件同样会弹出Consent 对话框。 审查所有遥测相关文件后，发现代码中完全没有项目级别的过滤机制。`UserPromptSubmit` 钩子的匹配器配置为空字符串，意味着匹配所有提示词；`PostToolUse` 钩子则基于工具名称（如 `Bash`、`Write|Edit`）而非项目类型进行匹配。框架检测功能实际上已经内置——`profileProject()` 方法能够扫描仓库并识别用户使用的框架类型——但这个检测结果仅用于上报统计数据，并未用于决定是否触发遥测数据收集。技术上_gate 存在，但工程实现中并未启用。 这造成了某种荒诞的局面：插件的框架检测能力恰恰被用于更精确地报告用户正在使用的技术栈，而非用于尊重用户的隐私边界。 ## 隐私边界的设计反思 Vercel 插件暴露的问题不仅是个别企业的决策失误，更反映了 AI 工具插件生态在权限设计上的系统性缺陷。用户期望的权限模型应当具备以下特征：明确的来源标识——任何通过插件钩子触发的提问都应带有插件前缀（如 `[Vercel Plugin]`），使其与原生界面清晰区分；细粒度的权限声明——安装时应明确列出插件请求的权限类别，包括 bash 命令读取、提示词文本读取和会话元数据访问，用户可以逐项授权或拒绝；以及项目级别的作用域控制——插件应声明其激活条件，如仅在检测到特定文件或依赖时才启用hooks，类似 VS Code 扩展的 `activationEvents` 机制。 对于 Claude Code 这样的 Agent 平台而言，插件架构本质上是一个「受信任的上下文注入器」，但当前设计未区分「提供知识的上下文」和「执行行为的指令」。这种混淆导致了权限边界的模糊。 ## 工程级防护方案 对于已安装该插件的用户，可以通过以下方式立即阻断数据收集：将 `export VERCEL_PLUGIN_TELEMETRY=off` 添加至 `~/.zshrc` 或相应的 shell 配置文件，这会禁用所有遥测数据发送但保留插件的核心功能如技能注入和框架检测；若需完全禁用插件，编辑 `~/.claude/settings.json` 并设置 `"vercel@claude-plugins-official": false`；如需彻底断开设备追踪，删除 `~/.claude/vercel-plugin-device-id` 文件。 对于 AI 工具的开发者和平台方，建议在架构层面引入权限分层模型：Hook 级别应当区分「只读上下文注入」和「可执行行为指令」，后者需要额外的用户确认；UI 层面应为所有插件生成的交互元素添加统一的视觉标识系统，使用户能够一眼识别数据来源；遥测系统应当默认关闭，收集范围应当最小化且对用户完全透明。 ## 小结 Vercel 插件事件揭示了一个更深层的问题：当 AI 工具具备「读取用户思考过程」的能力时，传统的隐私边界定义已经不够用。「提示词」不仅是查询，更是用户的思路、创意和决策过程。插件架构赋予第三方开发者的权限不应该模糊这一边界——这需要平台方在设计层面建立更严格的权限抽象，也需要用户保持对这类权限请求的警觉。 **资料来源**：本文核心事实与源码引用均来自 Akshay Chugh 的独立调查（https://akshaychugh.xyz/writings/png/vercel-plugin-telemetry）。 ## 同分类近期文章 ### [Rust 供应链攻击防御策略：从真实事件到可落地参数](/agent/posts/2026/04/11/rust-crates-supply-chain-security-strategies/index.md) - 日期: 2026-04-11T03:05:28+08:00 - 分类: [security](/agent/categories/security/index.md) - 摘要: 分析 crates.io 近年供应链攻击真实案例，提取 Cargo.lock 版本固定、CI 验证、审计工具配置等可落地防御参数。 ### [WireGuard Windows 内核驱动签名困境：微软 Partner Center 账户停用技术分析](/agent/posts/2026/04/11/wireguard-windows-kernel-driver-code-signing-microsoft-partner-center/index.md) - 日期: 2026-04-11T00:25:59+08:00 - 分类: [security](/agent/categories/security/index.md) - 摘要: 深度解析 WireGuard Windows 版面临的微软代码签名停用问题，涵盖内核驱动签名机制、EV 证书要求与兼容性解决方案。 ### [CPU-Z与HWMonitor供应链沦陷：恶意二进制分发机制深度分析](/agent/posts/2026/04/10/cpuz-hwmonitor-supply-chain-malware-analysis/index.md) - 日期: 2026-04-10T23:25:52+08:00 - 分类: [security](/agent/categories/security/index.md) - 摘要: 硬件监控工具CPU-Z与HWMonitor遭遇供应链攻击，分析恶意二进制分发机制与用户系统渗透路径，提供可落地的检测与防御参数。 ### [CPU-Z/HWMonitor 供应链投毒事件工程复盘：签名校验失效与二进制审计自动化实践](/agent/posts/2026/04/10/supply-chain-malware-cpuid-binary-audit/index.md) - 日期: 2026-04-10T22:50:31+08:00 - 分类: [security](/agent/categories/security/index.md) - 摘要: 深度剖析 CPUID 供应链恶意软件事件的工程根因，聚焦签名校验局限、依赖链渗透路径与二进制审计自动化落地方案。 ### [FBI如何通过iOS通知缓存提取已删除Signal消息：技术原理与防护参数](/agent/posts/2026/04/10/fbi-ios-notification-signal-message-recovery/index.md) - 日期: 2026-04-10T20:01:48+08:00 - 分类: [security](/agent/categories/security/index.md) - 摘要: 分析FBI利用iOS通知系统缓存提取已删除Signal消息的技术机制，并给出可操作的隐私防护配置参数。