# Claude Code 被指将真实邮箱塞进 User-Agent，谁该为外泄数据负责？ **Summary:** 一份 GitHub 报告称 Claude Code 在未经许可的情况下将用户真实邮箱放入 HTTP User-Agent 头部；我认为智能体工具需要对离开本地的数据单独授权。 - Canonical: https://markhuang.ai/zh/news/claude-code-user-agent-email-permission-gap - Language: zh-CN - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-08-11 - Section: News - Tags: AI, Claude Code, 隐私, 开发者工具, 智能体安全 - Source: [GitHub Issue](https://github.com/anthropics/claude-code/issues/78431) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![一个 AI 编码智能体向服务器发送多层网络元数据，其中包含一个意外的个人身份令牌](https://cdn.markhuang.ai/news/claude-code-user-agent-email-permission-gap/hero.webp) *批准连接只说明了智能体能去哪里，并不一定说明哪些身份信息会随行。* 一份[针对 Claude Code 的 GitHub 问题报告](https://github.com/anthropics/claude-code/issues/78431)称，该工具在未征得用户同意的情况下，将其真实邮箱地址放入了 HTTP `User-Agent` 请求头中。该报告于 2026 年 7 月 17 日提交，指出问题出现在 macOS 系统 IntelliJ IDEA 终端中的 Claude Code 2.1.212 版本，并称这是一个回归问题。 目前公开的信息仅此而已。问题报告中没有请求抓包、脱敏后的请求头、具体命令或复现步骤。Anthropic 已将其标记为 `area:networking`、`area:security`、`bug` 和 `needs-info`。因此我的结论保持谨慎：这并非已确认的 Claude Code 漏洞，但它暴露了一个编码智能体尚未清晰解答的权限问题——批准某个工具或目标，是否也意味着批准智能体往请求里塞进所有个人信息？ ## 这份报告只是指控，而非事后复盘 从现有问题描述中，我无法判断邮箱地址的来源。可能是提示词里带进来的，也可能是本地配置、脚本注入、工具本身要求，或者产品其他环节写入的。报告也没说请求发往哪个服务器，当时用的是哪种权限模式。这些缺失的细节决定了问题到底是产品行为、模型行为、工具行为，还是单纯的误解。 在称之为漏洞之前，我想看到确切的工具调用和脱敏后的出站请求副本。我还想知道邮箱从哪来的、用户执行前看到了什么、这个行为在 2.1.212 版本上能不能复现。在那之前，所谓的信息泄露仍然只是未经验证的说法。 证据缺失不代表权限问题就不存在了。如果指控属实，用户可能以为自己只是授权智能体分析某个工具，但智能体却把这当成可以自行选择公开身份的许可。这两个决定不应该捆绑在一起。 ## 工具授权并未说明哪些数据可以外泄 Claude Code 的[权限模式文档](https://code.claude.com/docs/en/permission-modes)提到，手动模式会在执行 Shell 命令和网络请求前询问用户，而更宽松的模式则允许更多工作无需中断地进行。更详细的[权限参考文档](https://code.claude.com/docs/en/permissions)则围绕工具、命令、文件和域名来划定规则边界。这些边界很有用，但还是留下了一个独立的问题：哪些数据可以从本地机器进入已经批准的请求？ 用户完全可以合理地批准向某个域名发送请求，同时拒绝在请求头里带上邮箱地址。同样的区分也适用于仓库名、用户名、本地路径、客户标识符和凭证。目标控制决定了数据能去哪，读取控制决定了智能体能访问什么，但两者都没法自动说明哪些被访问的数据可以向该目标披露。 > **Info:** > > 我会把智能体的出站检查拆成四道关卡：这个工具能不能跑？能不能访问这个目标？能不能读取这个本地值？这个值能不能随这次请求发出去？ 提示疲劳让这个问题雪上加霜。[Anthropic 对构建 Claude Code 自动模式的描述](https://www.anthropic.com/engineering/claude-code-auto-mode)提到，用户接受了 93% 的手动提示。如果几乎每个弹窗都被批准，那弹窗本身就扛不起整个隐私模型了。安全的默认值很重要，预览界面也要把携带身份信息的数据明确标出来，而不是把它埋在命令里。 ## `User-Agent` 应该标识软件，而非用户 HTTP 标准给这个投诉提供了更硬的依据。[RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#section-10.1.5) 把 `User-Agent` 定义在产品标识符和版本信息的范围内，要求发送方只填必要信息，并警告不要塞入过于细粒度的细节——因为这些细节可能在违背用户意愿的情况下暴露其身份。 同一标准还专门设了[`From` 请求头](https://www.rfc-editor.org/rfc/rfc9110.html#section-10.1.2)来放邮箱地址。它规定非机器人用户代理不应在未经用户明确配置的情况下发送这个字段，而机器人代理则应提供有效的联系方式，方便服务器管理员找到运行者。机器人标明运营者确实有道理——一个可问责的机器人，通常比匿名机器人更像一个合格的网络公民。 前提是操作者自己选的地址。开发者完全可以给自动化请求配一个专用服务邮箱，这没问题。但智能体自己翻到一个个人地址，然后决定让它反复出现在服务器日志里——这是另一回事。我希望这类身份是专门为这个场景选的，而且在请求发出之前，目的地和可能被写入日志的情况都要说清楚。 ## 权限界面需要展示出站数据明细 对于网络操作，我希望授权界面能列出目标域名、请求方法、敏感请求头，以及构造请求时用到的本地数据来源。不需要暴露每一个字节，但至少应该标出哪些字段包含邮箱地址，并说明这个值来自当前提示词、Git 配置、环境变量、账户资料，还是别的地方。 Claude Code 已经有一个高级用户可以用的拦截点。它的 [hooks 文档](https://code.claude.com/docs/en/hooks)提到，`PreToolUse` 钩子会在工具调用前运行，能拿到工具输入，也可以阻止执行。这可以拦截已知的命令模式，也可以把请求强制过一遍本地策略检查。作为应急手段确实有用，但普通用户不应该为了不让个人邮箱出现在出站元数据里，还得自己写一个钩子。 产品需要把"工具能不能用"和"哪些信息可以往外发"这两件事分开。网络工具的允许规则可以授权连接，但哪些类型的个人数据可以经过这个连接，应该由另一套策略来决定。当智能体引入了一个新的身份值，授权界面应该明确告知，而且只在用户选定的范围内记住这个选择。 ## 我的看法 \#78431 号问题并不能证明 Claude Code 收集或泄露了谁的邮箱。但它确实暴露了一个现实：智能体做出一个出人意料的请求之后，用户手里能拿到的证据少得可怜。Anthropic 需要从报告者那里获取更多细节才能定位问题，而报告者也理应有一种方式，能在不再次公开邮箱的前提下把这些细节提交上去。 如果指控成立，把邮箱从 `User-Agent` 里拿掉只是最简单的修复。更重要的是让"哪些身份信息会外发"变成一个可见的产品决策。我很乐意让编码智能体去调用已批准的工具，但我不愿意让它在没给我看的情况下，就替我决定以什么身份面对那个工具。