xAI Grok Build CLI 网络分析：文件与仓库上传、存储目的地揭秘

xAI 的 Grok Build CLI 实际发送给 xAI 的内容网络层面分析这是一次经过严谨测量且可复现的拆解研究结果有捕获到的工件和复现命令作为支撑。所有捕获的流量均来自本人机器上的操作使用的是一个包含虚假“金丝雀”机密的一次性仓库未暴露任何真实凭证。0. 总结xAI 官方的 Grok Build 编码 CLIgrok在普通消费者登录时有三件事值得详细记录一是会将读取的文件内容包括 .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. 方法可复现环境为 macOSApple Silicongrok 0.2.932026 年 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 设置材料中提及且默认开启。对于“这在服务条款/选择加入协议中已有说明”的观点认为广泛的训练披露不等同于对特定机制的详细说明用户未被明确告知。“改进模型”开关没有作用无论开关状态如何整个仓库都会以相同方式上传退出选项控制的是训练而非代码是否被上传/存储。