AREX Feed Article
Claude Code 被曝向网站发送用户邮箱，Anthropic 回应称并非功能设计：v2.1.317 起内置拦截模块并开源
2026 年 11 月 5 日 22:13（UTC），GitHub 用户 taylor-edwards 在 Anthropic 官方 claude-code 仓库提交 ，报告 Claude Code 在执行网页请求时，把登录账号的邮箱地址写进 User-Agent（用户代理）请求头、发给了第三方网站，并称自己每天因此收到几十封诈骗邮件。四分钟后，这份报告被贴上 ，题为「Claude Code sends your email address to websites」；截至 11 月 6 日发稿，该帖已获 404 分、137 条评论（含回复）。
约一个半小时后，Anthropic 工作人员 poteat 在同一 issue 中回应：不存在「向网站分享邮箱」的功能设计；实际情形是模型遵循 Wikipedia 等网站要求脚本客户端在 User-Agent 中提供联系邮箱的策略，在 curl 调用中不可预期地带上了用户邮箱。他称自 v2.1.317 起，内置 mod（插件模块）cc-plugin-privacy 已确定性地拦截该行为，模块默认开启，其源码已公开在仓库的 mods/privacy 目录。截至目前，泄露出自用户自述，修复效果以 Anthropic 单方口径为准。
用户报告：网页请求的 User-Agent 里带着登录邮箱
他的描述是：Claude Code「在进行网页搜索时未经我允许，把我的邮箱通过 User-Agent 请求头泄露给了任意第三方」，每天涌入的诈骗邮件被他归因于此。报告运行环境为 macOS；issue 被加上 bug、platform:macos、area:tools、area:security 四个标签。
报告者给出三层反对理由：向网站提供真实邮箱，帮不到那些想屏蔽 agentic（AI 代理自动化）流量的服务；它不保护用户的网页匿名性；对诈骗者而言它是一座金矿。所以他的要求不是把它做成可选加入或可选退出的设置项，而是「从 harness（工具外壳）中彻底移除」。他还表示，正在把公司迁移到 Pi 加 OpenRouter，理由是对 Anthropic 保护隐私的能力失去信心。
评论区随之出现一串接龙式的「I was here」（我在现场）留言；有人讽刺道「企业很在乎你的隐私」，后面跟了一句「哈」。也有用户给出自保方案：xSetech 在 CLAUDE.md 里写了一份 User-Agent 白名单——邮箱只允许发给明确索要联系邮箱、且经他批准的站点（名单里目前只有 Wikipedia），其余站点必须先询问、批准后才能发请求。
Anthropic 回应：模型遵循了 Wikipedia 的 UA 政策
poteat 的第一条回应出现在 11 月 5 日 23:31（UTC）：「我们引入了一个名为 cc-plugin-privacy 的内置 mod，从 v2.1.317 起确定性地拦截这一行为。」他请用户在发现该 mod 的检查存在缺口时「尽快」反馈，并承诺像其他内置 mod 一样公开其源码；该模块可通过 /plugins 关闭。
约半小时后他补充了定性：「澄清一下：没有任何人把『向网站分享邮箱地址』实现为功能。模型可能高度不可预测。」他给出的三步场景是：Wikipedia 这类网站有政策，要求所有脚本客户端在 User-Agent 中提供联系邮箱以表明身份；用户让 Claude 去 Wikipedia 查资料；于是 Claude 在 curl 调用中把用户的邮箱发给了 Wikipedia。他把结论落在工程方法上——「这正是围绕模型行为建立确定性检查如此重要、也是我们需要解决对齐问题的原因」。同一条回应还确认，privacy mod 的源码已经公开在，任何人都可以查看这套拦截逻辑；而在第一条回应里，这还只是一句「会设法公开」的承诺。
拦截模块 cc-plugin-privacy 拦什么、不拦什么
已公开的 README 开头就承认了前提：模型的上下文中本就带有登录账号的邮箱，用于识别用户，这个 mod 做的是阻止该地址以「客户端联系方式」的形式发出去。技术上它只挂了一个 tool.check 钩子：当 Bash、PowerShell 或 Monitor 调用的输入中同时出现这个邮箱和一个 User-Agent 标识时，调用会被拒绝；邮箱的大小写变体和一次百分号编码都算数。触发拒绝时不弹确认框，任何权限模式下都不弹，已保存的允许规则和 auto 模式的分类器也解除不了它。
匹配面覆盖 curl -A、wget -U、PowerShell 的 -User 等写法，文档还特别说明 PowerShell 旗标可以用 en dash（–）、em dash（—）等变体连字符书写，照样匹配。但文档用一整节列出「拦不住的情形」：不带 User-Agent 的外发（URL、请求体、curl -u、From: 头）；WebFetch、WebSearch 和 MCP（模型上下文协议）工具的调用不在检查范围内；运行时计算的地址（如 $(git config user.email)）、变量、按名发送的文件、其他编码方式，也都能穿过检查。README 给自己的定性是：「一种善意防护，不是安全边界」，且只覆盖一种形态。为了让检查足够简单——整个测试就是两次词匹配、不做解析——一些误拦被有意接受，比如只是在地址旁边提到 User-Agent 字样的调用。
关闭方式也有多层：/plugin disable 或设置文件中的 enabledPlugins 开关（仓库级设置不算数）；一个每会话读取一次的服务端开关；已安装插件的钩子层级更高，可以推翻它的拒绝。
邮箱是怎么到模型手里的：七月以来的报告链
User-Agent 里的邮箱不是凭空出现的。2026 年 7 月 25 日，有用户在 claude-code 仓库提交 ，标题直指：账号邮箱（PII，个人身份信息）在未经同意、未作披露的情况下被注入模型的系统提示词。报告者称通过反编译发布包发现，Claude Code 会在每个会话向模型上下文注入一个 # userEmail 块——「用户的邮箱地址是 <账号邮箱>」，取值来自 ~/.claude.json 中的 oauthAccount.emailAddress；他称文档中没有任何披露，也找不到关闭它的设置。
那份报告记录的两种后果与这次 User-Agent 泄露如出一辙：模型曾在无人要求时把系统提示词的内容说了出来——「我的系统提示词告诉我，你的邮箱地址是……」；模型还在十次 git 提交中用 git -c user.email=<私人邮箱> 覆盖了本已配置好的仓库身份，按报告者的说法，靠 GitHub 的推送保护拦截才没进公共提交历史。评论区的类似报告持续累积：有人把近期垃圾邮件增多追溯到 Claude Code 在提交信息中泄露邮箱；有用户报告 agent 主动用其订阅邮箱覆盖了 git 身份，另一名用户在 v2.1.263 上确认该问题仍然存在。8 月 26 日，有用户复核 v2.1.246 时发现，注入块此后带上了一段约束文字——邮箱「仅可用于识别用户……切勿发送给无关服务，例如请求头、URL 或载荷，除非用户明确要求」——但地址本身照样注入；到 v2.1.289，又有用户观察到注入块变成了附着在每次出站请求上的 system-reminder。
报告者还在 #81138 中列出四份更早的相关报告，称最早可追溯到 2026 年 4 月，且它们都因「长期无活动」或被关联为重复而关闭，而非经过实质审查后被判定合理。从 7 月 25 日的这份报告，到 11 月 5 日 poteat 的回应，中间隔了三个多月。
讨论的火气与三个未闭合的问题
HN 帖子升温的同时，issue 下的讨论也转向 Anthropic 本身。用户 AlexErrant 留言：请先整理这个仓库里 5,000 多个 issue，而不是只盯着 Twitter、Reddit、HN 上刷屏的内容，7 月的原始 issue 就摆在那里。围绕同一现象的公开讨论早已开始：8 月 12 日 HN 上就出现过题为「Claude Code is leaking real email address as a User-Agent string in curl command」的；10 月下旬，HN 上又出现等帖子，继续指向同一行为。
这次回应留下三个具体的问题。第一，报告环境信息里列出的版本是 v2.1.318，已高于 poteat 称开始拦截的 v2.1.317，而报告没有说明泄露发生在哪个版本上——仅凭这份 issue，无法判断这是修复生效前的旧泄露，还是拦截存在缺口。第二，报告者要的是整体移除、连开关都不留，Anthropic 给出的却是一个默认开启、可经 /plugins 等多层开关关闭、文档自称「不是安全边界」的模块。第三，修复的实际效果缺少独立验证：mod 源码公开后，任何人都能核对检查逻辑的设计，但它在真实使用里拦不拦得住，目前只有 Anthropic 一方的说法。截至发稿，issue #107757 仍处于 open 状态。