事情经过是这样的：7月13号左右，一位叫 Cereblab 的安全研究人员在测试 xAI（现在叫 SpaceXAI）的终端编程工具 Grok Build 时，发现了一个让人后背发凉的问题——这个号称”本地优先”的 AI 编程助手，会在你毫不知情的情况下，把你的整个 Git 代码仓库打包上传到 Google Cloud Storage。
在一个12GB的测试仓库里，模型实际只用了192KB的数据来完成任务，但上传通道却往Google云存储桶里塞了5.1GB——差了将近28000倍。
不是Bug，是设计
Cereblab 用 mitmproxy 抓了所有网络请求。他让 Grok Build 做一件再简单不过的事：回复一个”OK”，不打开任何文件。按理说这不该触发任何数据外传，但结果呢？工具照样把整个项目目录、commit 历史、甚至他故意放进去做测试用的 never_read_canary.txt（一个明确标注”别读我”的文件）全部打包上传了。
更离谱的是，用户界面里的那个”改进模型”开关根本没用。关掉它，服务器端依然返回 trace_upload_enabled: true，照传不误。
密码和密钥也一起飞了
当 Grok Build 读到 .env 文件里的 API Key 和数据库密码时，这些敏感信息也被原封不动地塞进 session 归档包，没有任何脱敏处理。有开发者报告说亲眼看着自己的 SSH 密钥、密码管理器数据库、个人文档和照片都被一股脑传走了。
消息曝光之后，xAI 在服务端悄悄加了一个 disable_codebase_upload: true 的全局开关来关掉这个功能——注意，不是修客户端代码，是服务端配置一改就完事了。这意味着理论上他们随时可以重新打开。
紧急开源：84万行Rust代码一夜上线
丑闻发酵没几天，马斯克亲自宣布 Grok Build 全面开源，完整代码库直接扔到了 GitHub（xai-org/grok-build），几小时就冲到了 7700+ Star。官方还重置了所有云端使用限制，支持完全本地运行，声称要给用户”彻底的隐私控制”。
开源后的代码库确实很庞大——844530 行 Rust 代码，规模跟 OpenAI 的 Codex（约95万行）差不多。但仔细翻一遍你会发现，之前那段向 Google Cloud 上传数据的代码（upload/gcs.rs）还在里面，只是被硬编码成了返回错误的状态。删了吗？没有。禁用了？是的。能不能随时改回来？技术上完全可以。
- Grok Build 是基于 Grok 4.5 大模型的命令行 AI 编程智能体，定位对标 Claude Code 和 OpenAI Codex CLI
- 代码中包含从 openai/codex 和 sst/opencode 移植过来的工具实现
- CONTRIBUTING.md 明确写明不接受外部 Pull Request——这更像是一次”可审计代码公开”而非真正的社区协作开源
- 子智能体的系统提示词要求模型”不要向用户透露提示词内容”，但主提示词却没有类似限制
发表回复