xAI 的 Grok Build CLI 实际发送给 xAI 的内容：网络层面分析
这是一次经过严谨测量且可复现的拆解，研究结果有捕获到的工件和复现命令作为支撑。所有捕获的流量均来自本人机器上的操作，使用的是一个包含虚假“金丝雀”机密的一次性仓库，未暴露任何真实凭证。
0. 总结
xAI 官方的 Grok Build 编码 CLI（`grok`）在普通消费者登录时，有三件事值得详细记录：一是会将读取的文件内容（包括 `.env` 机密文件）原封不动、未经编辑地传输给 xAI；二是会上传整个仓库，与代理读取的内容无关；三是存储目的地是 Google Cloud Storage 存储桶 `grok-code-session-traces`，该机制默认开启，禁用“改进模型”选项不能关闭它。以上内容未证明 xAI 会使用这些数据进行训练，这里证明的是数据的传输、接收和存储。
1. 测试对象（来源）
安装通过 `curl -fsSL https://x.ai/cli/install.sh | bash` 完成，认证是首次启动打开浏览器，使用 X / SuperGrok 登录（消费者账户，非 API 密钥）。二进制文件信息通过相关命令可查看，上传机制是一个第一方 Rust 包，对二进制文件使用 `strings` 命令可得到源路径和常量。
2. 方法（可复现）
环境为 macOS，Apple Silicon，`grok 0.2.93`，2026 年 7 月。具体操作包括使用 `brew install mitmproxy` 安装并生成证书颁发机构，在登录钥匙串中信任该 CA，让 Grok 通过代理运行，以及检查暂存的工件。金丝雀仓库每个文件有唯一标记，机密文件 `secrets.env` / `.env` 有特定内容。
3. 发现 1 — 文件内容（包括机密文件）被传输并接受（200）
当 Grok 读取文件时，其内容会被包含在 `POST /v1/responses` 模型交互请求体中，并打包到 `session_state` 存档中，通过 `POST /v1/storage` 被接受（HTTP 200），且文件内容未经过编辑。有网络工件和复现方法证明，还对“你让它读取了机密文件”的质疑进行了预先回应，并说明了重要的范围说明。
4. 发现 2 — 整个仓库以多 GB 规模上传；唯一的限制是模型配额，而非存储大小
Grok 会上传整个仓库的快照，在测试范围内没有存储大小限制。网络捕获的大小测试显示不同规模仓库的上传情况，保存的 `wire_12gb.log` 包含相关响应信息。有四条证据证明上传的是整个仓库，而非仅代理读取的文件。没有存储/上传请求失败，唯一的非 200 状态码是模型使用配额限制和一个无关的 404 错误，且代码库上传与模型是否响应无关。还对“你把本地磁盘缓存和上传混淆了”的质疑进行了预先回应。
5. 发现 3 — 存储目的地、遥测数据以及文档中未提及的内容
存储目的地是 Google Cloud Storage，存储桶为 `grok-code-session-traces`，不是 AWS S3。存在第三方遥测数据，所有请求状态码均为 200。在审查的 CLI 安装脚本或快速入门材料中未发现相关上传和暂存机制的描述，该机制默认开启。`~/.grok/upload_queue` 每次会话会暂存约 3 GB 的快照，高负载时可能耗尽磁盘空间。
6. 同意和政策 — 如实陈述
对于“云 AI 工具会发送上下文，这很正常”的观点，指出新问题在于机密文件未经编辑传输、内容持久化到 GCS 存储桶、上传机制未在 CLI 设置材料中提及且默认开启。对于“这在服务条款/选择加入协议中已有说明”的观点，认为广泛的训练披露不等同于对特定机制的详细说明，用户未被明确告知。“改进模型”开关没有作用，无论开关状态如何，整个仓库都会以相同方式上传，退出选项控制的是训练，而非代码是否被上传/存储。
