Grok Build CLI 被曝偷偷上传用户整个代码库：含密钥、Git历史，远超同类工具
你的代码，可能已经被整份搬走了
7月13日，独立AI安全研究机构 Cereblab 发布调查报告：SpaceXAI 的 AI 编程工具 Grok Build CLI 会将用户的整个代码仓库——包括它被明确告知不要打开的文件、已从 Git 历史中删除的密钥——打包成 git bundle，静默上传至 Google Cloud Storage。
这不是理论推演。Cereblab 用 mitmproxy 代理拦截了 Grok 的全部流量，输入了一条最简单的提示词：
> "reply OK, do not open any files."
结果 Grok 照样发出 POST 请求，把整个仓库上传了。研究者克隆了抓包截获的 bundle，发现 47 个文件、4 次提交的完整历史全在里面——包括一个标记为 "CANARY-NEVERREAD" 的测试文件，Grok 根本没被要求读取它。
对比同类工具：只有 Grok 这么干
Cereblab 对比了四款主流 AI 编程工具的数据行为：其他主流工具（包括 Anthropic、OpenAI 和 Google 的编程助手）都只在本地工作或仅上传被读取的文件，Grok 是唯一一个默认把整个代码库搬上云的。
隐私开关名不副实
事件曝光后，xAI 做了两件事：
- 服务端悄悄关闭了上传：Cereblab 在 7 月 13 日重测时发现，Grok 的 /v1/settings 接口返回了
disable_codebase_upload: true，上传不再触发。但这个修复是服务端的全局开关，客户端的上传代码仍然存在。
- 推出 /privacy 命令：官方指向这个命令作为"隐私控制"，但 Cereblab 实测发现，/privacy 只是一个服务端保留策略的开关——你的数据照样离开你的机器，只是 xAI 声誉上"不留存"。而且这是 per-session 的，每次新会话都需要重新设置。
伦敦国王学院独立安全研究员 Łukasz Olejnik 博士确认，这种级别的数据保留"过度"，潜在风险包括"专有源代码、安全漏洞信息、个人数据、基础设施细节和凭证"。
修复是修复了，但信任呢？
Musk 在 X 上回应称所有已上传数据将被"完全彻底删除"，并呼吁用户允许 SpaceXAI 保留数据以"帮助调试"。
Cereblab 在第二个代码库上复现了同样的问题（269 个 blob、219 MB），其他研究者也独立确认。截至 7 月 14 日，Grok Build 0.2.99 版本已默认关闭上传。
但核心问题依然存在：一个 AI 编程工具的默认行为不应该是"把你的全部代码上传到云端"。正确的默认值是"不上传"，而不是"上传了，但你可以 opt-out"——尤其当 opt-out 本身也不完全管用时。
对开发者的提醒：如果你使用过 Grok Build CLI 的早期版本（0.2.93 及之前），建议立即轮换代码库中曾出现过的所有密钥和凭证，即使你当时已从 Git 历史中删除了它们。
---
基于多家媒体转述整理。主要来源：Cereblab 官方调查报告、The Verge。