独立安全研究员 @cereblab 上周发布了一份把 Grok Build CLI 拆到骨头里的线级流量分析报告。他通过 mitmproxy 抓包逆向了 xAI 官方编码 CLI（v0.2.93），结论简单直接：不管你让不让它读文件，它都会把你的整个 Git 仓库——包括完整提交历史和 .env 密钥——打包上传到 xAI 的 Google Cloud 存储库。报告附带完整的可复现工具包和八节证据附录，已在 HN 冲上首页。

xAI 的回应不是发公告解释。7 月 13 日凌晨，社区发现他们通过服务端远程开关，静默加了一个字段：disable_codebase_upload: true。客户端一行代码没改，SHA-256 哈希纹丝不动。

全量仓库上传，与模型读取无关

cereblab 设计了一个关键实验来区分"模型需要读的文件"和"CLI 偷偷上传的文件"。

他在仓库里放了一个 never_read_canary.txt，提示词明确写"Reply OK, do not read any files"。然后从抓包截获的 git bundle 里 git clone 下来——金丝雀文件的唯一标记一字不差地出现了。

规模测试更触目惊心：12 GB 的随机文件仓库，模型对话通道（/v1/responses）只传了 192 KB，存储上传通道（/v1/storage）送了 5.10 GiB——27,800 倍的差距。73 个约 75 MB 的分块全部返回 HTTP 200，一个没失败。cereblab 主动终止了抓包，上传还在继续。

上传目的地是 Google Cloud Storage grok-code-session-traces——这个名字直接硬编码在二进制文件里，旁边躺着完整的 Rust 上传管线：xai-data-collector/src/gcs.rs、storage_client.rs、file_access_tracker.rs、circuit_breaker_observer.rs。这不是 bug，是精心设计的架构。

在另一个真实代码库上重复实验，同样的 prompt，同样的 git bundle 上传。两个独立仓库，结果一致。

.env 密钥明文传输，跨工具收集数据

API_KEY 和 DB_PASSWORD 在两个通道里原样出现：模型交互的 POST /v1/responses 请求体，以及打包进 session_state 归档上传到 GCS 的压缩包。抓包文件可以直接 grep 出金丝雀密钥。cereblab 明确写道："Grok 读了 .env 文件，没有对其内容做任何脱敏处理。"

更让人警觉的是跨工具收集。Grok CLI 启动时会扫描 ~/.claude/ 目录来继承 Claude Code 的配置和 Skills——然后数据收集器把所有读取过的文件全部打包上传。一位知乎用户指出，这意味着 Claude 的明文 API 密钥一并被送到了 xAI 的服务器。

"改进模型"开关是摆设

cereblab 关掉了 Grok 设置里的"Improve the model"选项，重新跑了一轮测试。服务端 /v1/settings 返回的依然是 trace_upload_enabled: true。git bundle 照传不误。

HN 用户 goos 的评论直接用了 "diabolical" 这个词来形容对 opt-out 设置的无视。

这个开关只管数据是否用于训练，不管数据出不出门。cereblab 的表述很克制："我们没证明 xAI 用这些数据做训练，我们只证明了传输、接收和存储。"但在 HN 上，dannyw 的评论更直白："任何分布式系统工程师看到这个架构都会认出——这是在收集训练数据。"

沉默关闸比上传本身更说明问题

7 月 10 日，cereblab 完成抓包分析。7 月 12 日晚，中文科技博主开始传播。7 月 13 日凌晨，xAI 服务端悄悄加了 disable_codebase_upload: true。

整个过程：没有公告，没有致歉，没有解释这个功能为什么存在、收集了什么数据、数据被怎么用了。客户端上传管线代码完整保留，意味着随时可以通过远程开关重新激活。一位博客作者的评价一针见血："如果这是合理的、经过用户知情同意的功能，为什么被曝光后的第一反应是偷偷关掉？"

与 Claude Code 争议不在一个量级

今年早些时候 Claude Code 被曝在系统提示词里用不可见 Unicode 字符标记中国用户，引发了监管关注。但那本质上是偷瞒问题——没有采集或上传用户代码。

Grok CLI 是另一个层面的事。它上传的是完整的代码仓库、git 历史、跨工具的配置文件、明文 API 密钥。中文社区一位开发者的比喻被广泛转发："Claude Code 是往你的外卖订单上贴标签，Grok CLI 是把你家钥匙复制了一把，顺便把邻居家的也捎上了。"

HN 讨论区也出现了撕裂。有人觉得任何云 coding agent 都必须发代码到服务端才能工作，Grok 只是多做了 10%。有人从威胁建模角度说 AI agent 本来就不该接触密钥。但更多人追问的是知情权——上传机制没写在安装指南里，默认开启，关闭训练开关也不管用。

rvz 的高赞评论说得极端但反映了一种正在蔓延的情绪："Grok 和 Claude Code 都是恶意软件。"

charcircuit 提供了缓解方案：在 ~/.grok/config.toml 里设 disable_codebase_upload=true 可以跳过上传代码路径，静态分析确认了检查逻辑存在。phaseleza 则分享了一个完整的 bubblewrap 沙箱方案。但这些都是社区自救，不能替代 xAI 的正式承诺。

对于用过 Grok Build CLI 的开发者，cereblab 的建议很明确：轮换所有在受影响仓库中出现过的密钥。把 Grok CLI 视为全量上传的云服务——只在你能接受整个仓库离开本地机器的前提下使用它。

参考来源：

• What xAI's Grok Build CLI Actually Sends to xAI — cereblab 原始分析 (GitHub Gist)
• grok-build-exfil-repro — 可复现工具包 (GitHub)
• HN 讨论帖