Grok Build CLI 全量上传代码仓库，xAI 沉默关闸引知情权追问！
【Grok Build CLI 流量分析报告曝光】
独立安全研究员 @cereblab 上周发布了一份把 Grok Build CLI 拆到骨头里的线级流量分析报告。他通过 mitmproxy 抓包逆向了 xAI 官方编码 CLI（v0.2.93），结论简单直接：不管你让不让它读文件，它都会把你的整个 Git 仓库----包括完整提交历史和 .env 密钥----打包上传到 xAI 的 Google Cloud 存储库。报告附带完整的可复现工具包和八节证据附录，已在 HN 冲上首页。
【xAI 静默加字段】
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 视为全量上传的云服务----只在你能接受整个仓库离开本地机器的前提下使用它。