2026 年 7 月 10 日，一位署名 cereblab 的独立安全研究员在 GitHub Gist 上发布了一份长达 8 个章节的线级抓包分析报告，标题直接而克制：「xAI 的 Grok Build CLI 到底向 xAI 服务器发送了什么」。这份报告在 Hacker News 上迅速获得 447 点、167 条评论，引发了开发者社区对 AI 编程工具数据收集边界的激烈讨论。
报告的核心结论可以浓缩为一句话：在你完全不知情的情况下，grok 命令不仅在每次调用时把你的 .env 密钥文件原封不动地发往 xAI 服务器，还会把你的整个 Git 仓库——包括你从未让 AI 读过的文件——打包上传到一个名为 grok-code-session-traces 的 Google Cloud Storage 存储桶中。更关键的是，关闭 Grok 设置里的「改进模型」开关，根本阻止不了这一切。
分析方法是怎样部署的
cereblab 的实验设计遵循了安全研究中最可靠的原则：全程可复现，证据可检验。
他在 macOS（Apple Silicon）上安装了 grok 0.2.93（SHA-256: 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c），通过 mitmproxy 设置中间人代理截获所有 HTTP 流量。为了确保每一条泄露的数据都能追踪到具体源文件，他在测试仓库的各个文件中植入了独特的「金丝雀」标记字符串——包括一个伪造的 .env 文件，内含 API_KEY=CANARY7F3A9-SECRET-should-not-leave 和 DB_PASSWORD=CANARY7F3A9-DBPASS。
他在两个无关的真实代码库和一个人造的 12 GB 随机文件仓库上各自独立运行了实验。所有捕获的请求体和响应状态码都被保留为证据文件，并附上了 SHA-256 校验值。报告在 §7 里专门列了一个「我们没有证明什么」的清单，明确区分了「已证实传输」和「未证实训练」——这种严谨程度在行业报告里并不多见。
通道一：.env 文件被两条路径同时发送
cereblab 发现的第一个问题，是 Grok Build 对文件内容的传输方式。当 Grok 读取一个文件时，文件的全部内容被序列化进 POST /v1/responses 的模型轮次请求体中。.env 也不例外——API_KEY 和 DB_PASSWORD 的值以纯文本形式出现在解密后的请求体中，可以通过 grep 直接匹配到。
单就这一点而言，并不出人意料——任何云端编程助手都必须把代码上下文发给服务端才能工作。但 report 接着揭示了一个额外的、未经文档说明的持久化通道：同样的 .env 内容被打包进一个 session_state 归档文件，通过 POST /v1/storage 上传并被服务器以 HTTP 200 接受。cereblab 在归档被发送前抢夺式复制了暂存文件，解压后在其中完整提取出了所有的金丝雀密钥。
换句话说，密钥不仅被即时处理，还被持久化写入了一个远程存储桶——而且这个机制在 Grok Build CLI 的安装脚本和快速入门文档中完全没有提及。
通道二：整个仓库打包外传，不管你是否让它读
如果说通道一揭示的是「读了就传」，那么通道二揭示的是一个更根本性的设计：Grok Build 会在每次会话中把整个 Git 仓库打包上传，与 AI 实际读取了什么文件毫无关系。
证据链条分四层。第一层是二进制逆向：对 grok 二进制执行 strings 命令，可以发现 xai-data-collector、grok-code-session-traces、storage.googleapis.com 等 Rust crate 路径和常量字符串，直接点名了数据采集模块和存储目的地。
第二层是流量体量。在 12 GB 的随机文件仓库测试中——AI 从未被要求读取其中任何一个文件——/v1/storage 通道传输了 5.10 GiB 数据（73 个约 75 MB 的块，全部返回 HTTP 200），而模型通道 v1/responses 仅传输了 192 KB。两者相差约 27,800 倍。如果上传的是 AI 实际读取的内容，192 KB 不可能承载 5 GiB 的有效信息。这个体量差直接将上传锚定在了整个代码库，而非交互读取的文件上。
第三层是清单证据。在一个真实代码库的测试中，cereblab 抢在数据被发出前获取了 Grok 暂存的元数据文件 staged_base_tree_manifest.json——这份清单明确枚举了一个名为 src/_probe/never_read_canary.txt 的文件，而 Grok 从未被要求打开它。每个文件的 fileId 字段都是 gs://grok-code-session-traces/repo_changes_dedup/v2/…/sha256_… 格式。
第四层是决定性证据。在升级为 SuperGrok 账户后，cereblab 用「Reply with exactly: OK. Do not read or open any files.」作为提示词运行 Grok Build。这一次，Grok 将整个仓库打包为一个 Git bundle，通过 POST /v1/storage → 200 上传。用 git clone 复原这个 bundle 后，never_read_canary.txt 中的金丝雀标记完整出现——一个被告知绝对不能碰的文件，其内容以完整形态出现在了远程服务器接受的流量中。同样的实验在第二个独立代码库上重复执行，结果一致。
隐私开关是摆设
报告中最令开发者感到被欺骗的发现，是 Grok 设置中的「Improve the model」开关对数据上传毫无影响。
cereblab 关闭了这个开关后重新运行实验。Grok Build 仍然打包上传了整个仓库的 Git bundle，服务器端 /v1/settings 返回的配置中仍然显示 trace_upload_enabled: true、upload_enabled: true 和 session_registry_enabled: true。这个开关似乎只影响 xAI 是否可以使用已上传的数据进行模型训练，而完全不控制数据是否离开你的设备。
用报告中的原话来说：「Choosing to opt out does not stop your repository from leaving the machine.」（选择退出并不能阻止你的代码库离开你的机器。）
还有第三方遥测
除了 xAI 自己的两条数据通道，cereblab 还在抓包中发现了 POST api.mixpanel.com/track 和 /engage 请求（Mixpanel 分析服务），以及 POST grok.com/_data/v1/events 请求——全部返回 HTTP 200。
这些第三方遥测请求的存在意味着，即使开发者只关心 xAI 会不会拿到代码，使用 Grok Build 时你的使用行为数据也在同时流向多个外部服务。
社区的应对和缓解措施
HN 讨论中出现了几个值得注意的回应方向。用户 kordlessagain 在评论中贴出了实际可用的环境变量缓解方案：
export GROK_TELEMETRY_TRACE_UPLOAD=0
export GROK_TELEMETRY_ENABLED=0以及配置文件中的对应选项：[telemetry] trace_upload = false 和 [harness] disable_codebase_upload = true。不过需要说明的是，cereblab 在报告中明确表示他「没有找到可以禁用上传的设置」，但也没有穷举所有账户和配置组合——这些环境变量是否真正生效，目前还缺乏独立的线级验证。
另一个方向是沙箱化。用户 phaseleza 分享了使用 bubblewrap 隔离编程工具的经验：只允许工具读取工作目录，用只读挂载保护 .git 目录，隐藏敏感目录；在网络层面，通过 Unix socket 上的 HTTP 代理限制对外连接，仅放行指定的 LLM 提供商域名，同时阻断工具自身的遥测域名。
截至本文撰写时，xAI 尚未对 cereblab 的报告做出公开回应。
这意味着什么
云 AI 编程工具需要向服务端发送代码上下文，这是工作原理决定的，本身不是问题。cereblab 报告的价值在于用线级证据精确还原了三点被隐藏的事实：第一，密钥文件被无脱敏传输并持久化写入远程存储；第二，整个代码库——包括从未交互过的文件——以 Git bundle 形式离开设备，且与读取行为无关；第三，用户界面中唯一的隐私控制开关对此通道无效。
对于正在使用或考虑使用 Grok Build CLI 的开发者，这份报告提供了一个清晰的决策信息：在当前的版本（0.2.93）中，Grok Build 对本地代码的访问范围远超你显式交给 AI 的那几个文件，而能关掉它的开关目前尚不存在。
参考链接：
- cereblab 线级抓包分析报告（GitHub Gist）
- Hacker News 讨论帖
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。