Grok CLI 隐私门事件

中/ 2026 年 7 月 10 日，安全研究员 cereblab 发布了一份针对 xAI 旗下 Grok Build CLI 工具（版本 0.2.93）的 Wire-Level 网络抓包分析报告[1]，揭示了该工具在默认配置下存在严重的数据外泄问题。cereblab 通过 mitmproxy 拦截并记录了 Grok CLI 与 xAI 服务器之间的全部网络通信。

EN/ On July 10, 2026, security researcher cereblab published a wire-level analysis of xAI's Grok Build CLI (version 0.2.93)[1], revealing serious data exfiltration under default settings. cereblab used mitmproxy to intercept and record all network traffic between Grok CLI and xAI servers.

中/ 分析发现该工具存在 两条相互独立的数据传输通道。通道 A 为模型交互通道（POST /v1/responses），.env 文件中存放的 API 密钥与数据库密码均以 明文形式 出现在请求体中，未做脱敏处理[1]。通道 B 为仓库存储通道（POST /v1/storage），Grok CLI 在每次任务开始前与结束后分别将完整工作区打包为 before_codebase.tar.gz 与 after_codebase.tar.gz，静默上传至 xAI 控制的 Google Cloud Storage 存储桶 gs://grok-code-session-traces[1]。上传物为 git bundle 格式，包含所有受 Git 追踪的文件及完整提交历史。

EN/ The analysis found two independent data transmission channels. Channel A (POST /v1/responses): API keys and database passwords from .env files appeared verbatim and unredacted[1]. Channel B (POST /v1/storage): Grok CLI packaged the entire workspace into before_codebase.tar.gz and after_codebase.tar.gz, uploading them to xAI's GCS bucket gs://grok-code-session-traces as git bundles containing all tracked files and complete commit history[1].

中/ cereblab 设计了一组关键验证实验。他在测试仓库中植入标记文件 never_read_canary.txt，内含唯一标记字符串，随后向 Grok 发出指令："Reply with exactly: OK. Do not read or open any files." Grok 回复了 "OK"，但后台仍将整个仓库的 git bundle 上传完毕（HTTP 200）[1]。截获该 bundle 后，从未被读取的金丝雀文件中的标记字符串 原样重现。该结论在第二个无关仓库上得到了复现[3]。

EN/ cereblab planted a canary file never_read_canary.txt with a unique marker, then instructed Grok: "Reply with exactly: OK. Do not read or open any files." Grok replied "OK" while the entire repository's git bundle was uploaded via POST /v1/storage (HTTP 200)[1]. Cloning the captured bundle recovered the canary marker verbatim. The result was replicated on a second repository[3].

中/ 流量数据提供了无可辩驳的证据。在一个 12 GB 测试仓库上，模型交互通道仅传输约 192 KB，而存储通道传输了 5.10 GiB，分 73 个分块，全部返回 HTTP 200[1]。两个通道的流量比为 27,800 倍，证明上传内容为整个代码库，而非模型实际读取的数据。

EN/ The traffic data provided irrefutable evidence. On a 12 GB test repository, the model-turn channel transmitted 192 KB, while the storage channel transmitted 5.10 GiB across 73 chunks, all returning HTTP 200[1]. The ratio: 27,800×, proving the entire codebase was uploaded, not just files the model read.

中/ 尤为值得关注的是 跨目录数据采集。Grok CLI 为兼容 Claude Code，启动时会主动扫描 ~/.claude/ 目录。由于收集器逻辑为"运行时读取过的文件均纳入上传包"，导致 ~/.claude.json、全局 AGENTS 规则、Skill 文件及第三方 API 密钥被标记为 supplemental_file，跨目录上传至 xAI 服务器[4]。

EN/ Particularly concerning is the cross-directory data collection. Grok CLI scans ~/.claude/ at startup for compatibility. Because the collector packages every file read during runtime, ~/.claude.json, AGENTS rules, Skill files, and API keys were marked as supplemental_file and uploaded across directory boundaries[4].

中/ Grok CLI 内置的 "Improve the model" 开关同样引发质疑。关闭该开关后，服务器 /v1/settings 接口仍旧返回 trace_upload_enabled: true，仓库上传行为未受影响。该开关仅控制训练许可，与代码是否离开发送端机器无关[1]。

EN/ Grok CLI's "Improve the model" toggle also drew criticism. After disabling it, the server still returned trace_upload_enabled: true, and repository uploads continued. The toggle controls training consent, not whether code leaves your machine[1].

中/ 7 月 13 日凌晨，cereblab 发现 同一版本 客户端（SHA-256 哈希值未变化）收到的服务器响应中新增了 disable_codebase_upload: true 字段，上传行为随即停止[5]。cereblab 在六次后续测试中均未观察到 /v1/storage 上传。然而，对 v0.2.99 的独立分析发现，上传代码仍存在于二进制文件中，仅通过服务端标记压制[13]。

EN/ On July 13, the same client version (SHA-256 unchanged) received disable_codebase_upload: true from the server, and uploads stopped[5]. Six subsequent tests observed no /v1/storage uploads. However, analysis of v0.2.99 found the upload code still present in the binary, merely suppressed by a server flag[13].

中/ 7 月 14 日，SpceXAI 官方账号首次公开发表声明，指出团队用户可使用零数据保留（ZDR）模式保证代码不被留存；未启用 ZDR 的用户可通过 CLI 中的 /privacy 命令关闭数据保留，并删除此前已同步的数据[10]。

EN/ On July 14, the official SpceXAI account issued its first statement, noting that teams using Zero Data Retention (ZDR) have no code data retained; users without ZDR can use the /privacy command to disable data retention and delete previously synced data[10].

中/ Andrew Milich（SpceXAI）进一步澄清，/privacy 自 Grok Build 首发即对所有用户开放，并非企业用户专享，且可追溯删除已同步数据[10]。Elon Musk 随后转发声明，承诺此前用户数据将被 "完全彻底删除，零残留"[6]。

EN/ Andrew Milich (SpceXAI) clarified that /privacy has been available to all users since Grok Build's first release, not enterprise-only, and that toggling it retroactively deletes synced data[10]. Elon Musk pledged user data will be "completely and utterly deleted, zero anything whatsoever will remain"[6].

中/ 同日，cereblab 在同一抓包环境下对 四款主流编码工具 进行了对比测试[11]：Claude Code 2.1.204、Codex（gpt-5.5）、Gemini 0.38.2 和 Grok 0.2.93。在同等金丝雀仓库中，以两种提示词分别运行各工具，通过 mitmproxy 捕获全部流量。结果：Claude Code、Codex、Gemini 均未发现全量仓库上传行为，从未读取的金丝雀文件从未离开本地。Grok 是唯一的异常值。[11]

EN/ On the same day, cereblab conducted a comparative test of four mainstream coding tools[11]: Claude Code 2.1.204, Codex (gpt-5.5), Gemini 0.38.2, and Grok 0.2.93. On identical canary repositories with two prompts, all traffic was captured via mitmproxy. Result: Claude Code, Codex, and Gemini showed no whole-repository upload behavior; the never-read canary never left the local machine. Grok was the sole outlier.[11]

中/ cereblab 随后公开驳斥了 xAI 将 /privacy 描述为修复方案的表述："真正阻止上传的是服务端全局标记 disable_codebase_upload: true——无论你 opt in 还是 opt out 它都适用。/privacy 是一个每次会话的数据保留开关，不是解决问题的控制项。默认值应该是不上传。"[12]

EN/ cereblab publicly pushed back: "What actually stopped the upload was a silent global flag – disable_codebase_upload: true – that applies whether you opt in or out. /privacy is a per-session retention toggle, not the switch that fixed this. The right default is off."[12]

中/ The Register 进一步披露，有用户报告 Grok CLI 将其整个用户目录（包含 SSH 密钥、密码管理器数据库等）打开并上传[12]。Axios 指出，删除已上传数据并不能消除敏感信息已暴露的风险；目前仍不清楚受影响用户数量、哪些版本上传了仓库、数据存储了多久、是否被访问过，以及用户如何独立验证删除是否完成[14]。The Stack 报道了两名用户在检查日志后发现疑似私有仓库被外泄[15]。

EN/ The Register further reported that one user's entire home directory—including SSH keys and password manager databases—was opened and uploaded[12]. Axios noted that deleting uploaded data does not eliminate the risk that sensitive information was exposed; it remains unclear how many users were affected, which versions were involved, how long data was stored, whether it was accessed, and how customers can independently verify deletion[14]. The Stack reported two users who found evidence of private repo exfiltration in their logs[15].

中/ 若将此事与稍早前 Claude Code 被曝光的"后门"事件[8]相比较，二者性质存在 本质差异。Claude Code 的问题是在系统提示词中使用不可见 Unicode 字符对用户请求进行分类标记——该行为 未涉及代码采集、文件上传与密钥获取，实际隐私危害接近于零。而 Grok CLI 通过独立旁路通道，将完整代码库与其他工具的敏感配置文件打包上传至远端服务器，严重程度不可同日而语[4]。

EN/ Compared with the earlier Claude Code incident[8], the two cases are fundamentally different. Claude Code used invisible Unicode characters in system prompts for classification tagging—it did not collect code, upload files, or exfiltrate keys. Grok CLI uploaded entire code repositories and sensitive configuration files from other tools through an independent side channel[4].

中/ 此事件折射出 AI 编程工具领域更深层的 监管空白。当前 AI Agent 已拥有与系统管理员几乎相当的权限，但行业内既无标准要求其公开本地读取的文件列表，也无规范要求上传行为必须经过用户的显式同意。整个行业在隐私监管层面处于真空状态[4]。

EN/ This incident exposes a deeper regulatory vacuum. AI agents now possess administrator-level permissions, yet no standards require disclosure of locally read files, and no regulations mandate explicit user consent for uploads. The industry lacks a privacy regulatory framework[4].

中/ 对于曾使用过 Grok CLI 的开发者，建议立即采取以下措施：卸载该工具（curl -fsSL https://x.ai/cli/uninstall.sh | bash），删除 ~/.grok/ 配置目录；在 CLI 中运行 /privacy 命令检查并关闭数据保留；轮换所有可能暴露的 API 密钥与数据库凭证。社区已发布隐私加固脚本[9]，可供参考。

EN/ For developers who have used Grok CLI: Uninstall (curl -fsSL https://x.ai/cli/uninstall.sh | bash), delete the ~/.grok/ directory, run /privacy to disable retention, and rotate all potentially exposed API keys and database credentials. A community hardening script is available[9].