xAI Grok Build CLI 实际发送给 xAI 的内容 - 一项线路级分析 (grok 0.2.93)。一个经过测量的、可重复的拆解。发现结果由捕获的文物（端点、HTTP 方法、状态码、字节大小、主机）和重现命令支持；在观察到的实时情况但未保留为文件的情况中，第 7 节明确说明。第 8 节是一个证据附录，包含 SHA-256 和 "我们未能证明的内容" 列表。所有捕获都是我自己在我自己的机器上的流量，使用包含虚假 "探针" 秘密的临时仓库——没有暴露真实凭证。0. 摘要 xAI 官方的 Grok Build 编码 CLI ( grok )，在正常消费者登录时，有三项值得精确记录的事情：它逐字传输读取的文件内容——包括一个 .env 秘密文件——给 xAI，没有修改和删除。秘密出现在两个通道中：实时模型请求 ( POST /v1/responses ) 和通过 POST /v1/storage 上传且被接受的 session_state 存档 (HTTP 200)——该端点将二进制文件路由到 grok-code-session-traces GCS 存储桶（见第 5 节）。它上传整个仓库——每个跟踪文件的内容加上 Git 历史——与代理读取的内容无关。Grok 将工作区打包并通过 POST /v1/storage 上传。直接证明：在真实代码库上，使用 prompt "回复 OK，不要读取任何文件"，Grok 将整个仓库上传为 Git 包 ( POST /v1/storage → 200 )；从捕获的包中 git clone 可以恢复一个代理被告知不该打开的文件——src/_probe/never_read_canary.txt——其独特标记逐字保留，以及完整的 Git 历史（附录 uploaded_repo.bundle）。而且它具有可扩展性：在一个 12 GB 的从未读取的随机文件仓库中，/v1/storage 移动了 5.10 GiB，所有操作返回 HTTP 200（在中间流复制），而模型请求通道仅移动了 192 KB——一个 ~27,800× 的比率将上传锁定到代码库，而不是读取的内容。没有任何存储上传失败；唯一非 200 的是一个模型使用配额 (402/429)，在 /v1/responses 上和一个无关的404——不是存储大小上限。存储目标是一个 Google Cloud Storage 存储桶，grok-code-session-traces（而不是 AWS S3）——在二进制文件和捕获的 metadata.json 中逐字命名 ( gs://grok-code-session-traces/… )。我没有在 CLI 的安装/快速入门材料中发现这个机制（不是全面的文档审计——第 7 节），它默认是活跃的，禁用 "改善模型" 并不会关闭它（/v1/settings 仍返回 trace_upload_enabled: true ; 第 6 节）。所有这些并不能证明 xAI 在这些数据上进行训练——这是第 6 节中探讨的政策问题。已经证明的是，数据的传输、接受和存储。1. 测试主题（来源）安装：curl -fsSL https://x.ai/cli/install.sh | bash # → ~/.grok/bin/grok 授权：首次启动打开一个浏览器 → 登录到 X / SuperGrok（消费者账户，而不是 API 密钥）二进制身份（重现：file $(readlink -f ~/.grok/bin/grok); ~/.grok/bin/grok --version; shasum -a 256 $(readlink -f ~/.grok/bin/grok)）： ~/.grok/bin/grok -> ../downloads/grok-macos-aarch64 Mach-O 64 位可执行文件 arm64 grok 0.2.93 (f00f96316d4b) SHA-256: 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c 上传机械是一个第一方 Rust crate。对二进制文件的字符串输出产生这些源路径和常量（重现：strings <binary> | grep -E 'xai-data-collector|grok-code-session-traces|storage.googleapis'）：crates/codegen/xai-data-collector/src/gcs.rs crates/codegen/xai-data-collector/src/storage_client.rs crates/codegen/xai-data-collector/src/queue.rs crates/codegen/xai-data-collector/src/file_access_tracker.rs crates/codegen/xai-data-collector/src/circuit_breaker_observer.rs crates/codegen/xai-grok-shell/src/upload/{gcs,turn,trace,manifest}.rs grok-code-session-traces storage.googleapis.com "通过代理上传字节到 GCS" 2. 方法（可重复）环境：macOS、Apple Silicon、grok 0.2.93，2026 年 7 月。brew install mitmproxy；运行一次以在 ~/.mitmproxy/ 中生成 CA。在登录钥匙串中信任 CA（无 sudo；Grok 不会针对其进行证书绑定）：security add-trusted-cert -r trustRoot -k ~/Library/Keychains/login.keychain-db \, ~/.mitmproxy/mitmproxy-ca-cert.pem 通过代理运行 Grok（一个 mitmdump 附加组件按请求日志记录：方法、主机、路径、响应状态、请求字节大小；并保存 xAI 主机的请求正文）：HTTPS_PROXY=http://127.0.0.1:8080 SSL_CERT_FILE=~/.mitmproxy/mitmproxy-ca-cert.pem \ grok -p "<prompt>" --cwd <repo> 对于分阶段的文物检查，在运行过程中复制 ~/.grok/upload_queue/*，然后 gzip -dc | tar -xO . 探针仓库：每个文件携带独特标记，因此在捕获的流量中出现的任何内容都可以明确追溯到文件。秘密文件 secrets.env / .env ：API_KEY=CANARY7F3A9-SECRET-should-not-leave DB_PASSWORD=CANARY7F3A9-DBPASS 3. 发现 1 — 文件内容，包括一个秘密文件，被传输并被接受 (200)。声明：当 Grok 读取文件时，其内容被传输给 xAI——序列化为 POST /v1/responses 模型请求主体，并打包在...