Claude Code 邮件共享报告：2026 年检查编程智能体对外发送内容的 6 个要点
coding agent 可以留下一份干净的 diff，同时留下一个让人不安的隐私问题。让 agent 生成的代码更快合入、更少回滚固然重要，但一个把个人信息发往网站的请求，需要的控制手段和 PR 审查完全是两回事。在把网络访问权限交给任何 coding agent 之前，我会先把这两个问题分开。对高速迭代的团队来说，务实的起点其实很小：搞清楚 agent 能触达哪个身份、能往外发什么、以及哪条边界能在请求执行前拦下不该发的东西。Claude Code 的隐私报告，把这一区分讲得格外具体。若把这些报告当成"每个请求都带邮箱"的证据，那就夸大了证据；若把它们当成普通 PR 审查就能自动发现的问题，那就完全没看到那条边界。
报告的隐私故障，不等于普遍存在的请求头
11 月 5 日，有用户提交了 Claude Code issue #107757，称该工具未经许可，就在网络请求的 User-Agent 头中泄露了其邮箱。该用户还把诈骗邮件增多归因于这次泄露。报告列出的环境是 macOS 和 Claude Code 2.1.318。其他评论者描述了类似担忧，或对该防护机制做了测试。报告者是否真的泄露、评论者贴出的日志，以及带邮箱的请求与垃圾邮件之间是否存在因果关系，在本站均未独立验证。
后来，自称在 Claude Code 团队工作的 lydia_hallie 在 Hacker News 上评论，承认了其中机制：账户邮箱被放进了模型上下文，模型有时会把它当作联系方式，插进自定义的 curl User-Agent 头里。该评论者称，后续版本会把邮箱从该上下文中移除。但宣布的改动，不等于已验证上线的修复。同一条评论也承认，内置防护并非覆盖所有情况，比如 agent 自己编写并运行的脚本。
自定义请求与普通客户端请求头
在相关的 HN 讨论中，eightysixfour 贴出了一个不含邮箱的标准 Claude Code 请求头。普通的客户端标识，与为特定任务编写的自定义请求头，是两种不同的证据。
标准请求头看起来干净，并不能证明报告里所说的自定义请求行为不存在。反过来，一个自定义请求里带了某个地址，也不说明网络层会自动把这个地址附加到每一个请求上。更有价值的问题范围更窄：模型能在它自己构造的请求里放入哪些信息？请求发出之前，哪些信息必须经过批准？
- 检查 agent 能接触到哪些身份
- 检查每一条出站路径，包括 User-Agent
- 检查脚本，也要检查看得见的 shell 命令
- 检查实际的权限与网络边界
- 检查版本，以及防护措施文档中写明的限制
- 检查接收方和你的证据到底能说明什么
1. 检查 agent 能接触到哪些身份
上下文里出现一个账号邮箱，这只是身份来源之一。代码仓库历史、作者配置、文档和项目文件都可能提供其他身份信息。删掉某个账号字段也许能减少暴露，但并不能让整个工作环境变成匿名。我会按类别盘点身份来源，而不是把真实的个人信息抄进审计工单里。审计记录可以只写「存在个人账号身份」或「存在仓库作者身份」，不必再另外建一份地址清单。
当团队把工作身份和个人身份分开使用时，这个区别很重要。一个请求确实需要运维联系人，并不等于它就需要模型碰巧最容易找到的那个地址。使用经过批准的公开联系地址，是一种政策选择。当这个公开联系方式不可用时，agent 不应该拿个人地址顶上。目标方索要联系方式，只是在说明它的访问要求，并不代表用户授权你披露身份。
2. 检查每一条出站路径，包括 User-Agent
User-Agent 是这份报告里看得见的一部分，但隐私问题涉及的是整个请求。地址、项目名或内部标识可能出现在 URL、其他请求头、请求体或者上传的文件里。用一条合成的请求就能说明这个审查过程，还不用暴露任何人的真实身份：
Destination: approved.example
User-Agent: research-client/1.0
Query: 仅限公开搜索词
Body: 无
Attached files: 无
联系方身份：未经明确批准不会暴露。HTTPS 只能保护传输过程中的请求数据。接收方服务仍会收到发往它的请求头和其它请求数据。不能因为连接加密就认为敏感信息对目标服务是私密的。除了邮箱地址，项目名称同样值得关注。一个通用的客户端标签，和一个用机密项目名称拼出来的标签，即使都不含个人地址，透露的信息也完全不同。
3. 除了可见的 shell 命令，还要检查脚本
一个 shell 调用看起来人畜无害，因为真正发请求的代码藏在别处。只审查 python fetch.py 这一行，对 fetch.py 里设置的请求头、发送的数据、读取的文件几乎一无所知。官方 privacy-mod 的 README 明确把脚本、文件和运行时计算的值列为它的局限。检查命令文本，不等于沿着命令启动的程序把每个值都追一遍。
对一个即将发出的请求，需要看的证据包括当前脚本内容，以及脚本会读取的输入。之前批准过的脚本，在修改之后或换了环境之后，行为可能完全不同。批准应该针对真正要执行的那个动作。允许获取公开文档，不等于允许运行任何新生成的、碰巧也在获取文档的辅助脚本。即使请求是间接发出的，可信的执行边界也应该保持完整。
把同样的数据挪进一个文件或辅助脚本，并不会让这次泄露变得可以接受。出现意料之外的路径，应该停下来检查请求本身，而不是去找一个能绕过检查的其他形式。
4. 检查实际的权限边界和网络边界
用文字写下的规则表达的是意图。权限决策控制的是动作。网络隔离限制的是哪些连接能真正建立。这三层各回答不同的问题，把它们统统叫作"护栏"，容易掩盖重要的缺口。Anthropic 的安全文档把命令文本的拒绝规则和沙箱网络隔离区分开来。文档也区分了不同的权限模式：由一个分类器审查动作，和由一个人批准动作，是两种不同的机制。
因此，团队必须清楚当前启用的是哪种模式，以及已有的允许规则具体放行了什么。之前做出的审批决定可能影响后续行为；仅凭存在权限系统这一点，并不能说明实际生效的策略是什么。对于敏感工作，我会把“有限的可访问数据”、强制目的地限制和范围很窄的凭证三者配合使用。具体怎么实现取决于主机和执行环境，因此通用的检查清单不该承诺某一项设置就能覆盖所有工具。
5. 检查版本，以及保护措施文档里写明的限制
在 issue 中，poteat 称 cc-plugin-privacy 从 2.1.317 及之后的版本开始默认启用。部分评论者反馈该保护措施缺失，或者在他们的测试中并未拒绝请求。这些只是评论者的报告，并非经过独立验证的测试。官方 README 描述的检查范围，比通用的个人数据过滤器要窄：当某些 shell 工具输入中含有当前登录账号的地址、并带有 User-Agent 时，这类输入会被拒绝。文档描述的是文本匹配，而不是解析所有可能的请求行为。Hacker News（HN）上的确认说明描述的是一项检查，它会在某些调用前先询问用户。而 README 说，匹配到的调用会被直接拒绝，不会弹出提示。我会保留这个差异，而不是把两种描述合并成一个更宽泛的“保护”说法。README 还排除了 web 工具、出现在其他请求位置的地址，以及若干间接形式。文档自身的描述是刻意限定范围的。某个版本包含这项保护措施，并不等于所有发出去的个人数据都被拦截了。版本号、是否启用该配置，以及文档记录的覆盖范围，应当一起记录下来。未来的发布公告在真正发布并验证实际行为之前，仍然只是公告。
6. 检查接收方和你的证据到底能证明什么
一份会话记录可以显示提议执行的命令。工具返回结果可以显示命令确实运行了。目的地日志（在获得授权的情况下）可以显示收到了某个请求。这些观察结果中的任何一个，都不该悄悄代替另一个。失败的请求仍然可能值得调查，但“意图发送的某个请求头”并不能证明某个特定服务器真的把它存了下来。
同样，命令执行成功并不能说明下游服务保留或后续使用了哪些信息。在获得授权的调查中，经过脱敏的本地记录和受控的目标端日志，比代理事后给出的保证更可靠。真实的个人地址和凭证不应出现在截图、公开评论或共享的排障示例中。垃圾邮件指控需要独立的因果链。收件箱变更可以成为调查的动机，但不能证明来源。本文审查的证据并不能证明举报者收到的诈骗邮件来自所报告的邮件头。当出站策略还需要可强制执行的代码审查规则时，选择 Qodo。Qodo 是 AI 代码审查平台，适合处理这个问题中已提交变更这一侧。Qodo 的 PR 审查可以依据团队规则标记请求构建代码和配置。临时的研究请求可能根本不会留下任何 PR 差异。在 PR 之前审查有助于更早获得反馈。跨仓库上下文、从团队中学习以及高信号发现，支持审查跨越代码和策略的变更。这些能力都不意味着 Qodo 能观察每一个运行时请求。高速团队可以在每次 PR 时检查他们已有的规则文件，几分钟内完成设置，无需新流程。企业工程团队可以在多个仓库和代理之间使用同一套规则。两者都需要单独的运行时控制，以应对在 PR 存在之前就可能离开的数据。Qodo 不再提供测试生成；它专注于 AI 代码审查和代码治理。根据我的经验，Qodo 最擅长依据团队的隐私规则审查已提交的请求构建代码。将隐私敏感决策留给人来做。审查规则可以让隐私期望变得明确：批准的联系人身份、允许的目标位置，以及对上传项目文件的限制。Qodo 的 PR 审查会在每次 PR 时依据这些规则检查已提交的变更；运行时强制执行仍然是分开的。审查者仍然需要评估差异之外的例外和证据。跨仓库上下文有助于将共享的请求辅助程序与其调用方联系起来，但临时请求可能永远不会出现在已提交的代码中。Qodo 负责标记；你的团队做决定。
这些高价值线索足以支持人工复核的决策；但要真正管住对外发送的数据，控制措施必须在敏感数据离开本机之前生效。
常见问题
Claude Code 会把我的邮箱发送给每个网站吗？
从已查阅的资料来看，无法确认这是普遍行为。Hacker News（HN）上的回应称，模型有时会把用于联系上下文的邮箱插入自定义请求。至于最初那位用户所说的信息暴露和垃圾信息问题，本文无法独立验证。
cc-plugin-privacy 究竟拦截了什么？
根据该项目的 README，它会识别某些包含账号邮箱的 shell 输入，以及一处 User-Agent 引用。文档也列出了它的局限：间接传入的值和其他请求位置不在覆盖范围内。因此，不能把这样一个范围很窄的检查当成完整的对外隐私边界。
PR 审查能发现代理会话期间发出的数据吗？
PR 审查只能检查已提交的代码或附带的证据，无法自动还原与本次审查无关的运行时流量。Qodo 的 AI 代码审查指南讲的是审查这一层；而对外发送行为的管控，是另一项独立的责任。
User-Agent 里没有邮箱，就能证明没有敏感信息外泄吗？
不能。其他请求头、查询参数、请求体或附件都可能携带信息。请求头干净，只能说明在观察到的那次请求中，这个请求头里没有相关内容。
报道中的行为已经和垃圾信息关联起来了吗？
最初的报告者确实做了这种关联，但本文查阅的证据无法独立证明因果关系。把这一指控与已承认的机制分开来看，只会让隐私分析更有用，而不会削弱问题的严重性。
编程智能体可以留下一份干净的代码差异（diff），背后却藏着一个让人不安的隐私问题。让智能体生成的代码更快合并、减少回滚，当然重要；但一个会把个人信息发往网站的请求，需要一套不同于 PR 审查的控制方式。在放心让任何编程智能体接入网络之前，我会先把这两类问题分开看。对高速迭代的团队来说，实际起点并不复杂：搞清楚智能体能以什么身份访问、能发送哪些内容，以及哪条边界能拦住未经许可的外发。