马斯克连夜开源Grok Build，但84万行代码里还留着上传用户整个代码库的痕迹
埃隆·马斯克已确认，SpaceX 现已采用 Apache 2.0 许可证开源 Grok Build。
几天前，这款 AI 工具被曝会收集用户的整个代码仓库——将完整的源代码库连同 Git 提交历史一并上传到 Google Cloud Storage，上传的数据量大约是编码任务实际所需数据的 27,800 倍。
7 月 14 日，马斯克承诺将彻底删除此前上传到 SpaceXAI 的所有用户数据。他还表示，在对代码库完成安全漏洞审计后，SpaceX 将开源 Grok Build，以增强人们对这一产品的信任。
随后，SpaceXAI 兑现了承诺，在 GitHub 上正式开源了这套智能体编程框架。该公司在一篇 X 帖子中表示：“开源 Grok Build 可以让任何人都能参与构建可靠且强大的框架。”
开源不到 20 个小时，Grok Build 已在 GitHub 上收获 1.21 万颗 Star。
84 万行 Rust 的构成
Grok Build 的代码库规模相当惊人，共包含 844,530 行 Rust 代码。这个数字由 Simon Willison 使用自己的 SLOCCount 工具计算得出，不包含空白行和注释，其中似乎只有约 3% 属于直接引入的第三方代码。
他们自主开发了整套终端应用平台，包括界面、Markdown 和 Mermaid 图表渲染；自行实现了代码复制、文件监控、代码图谱、熔断器和上传队列等基础设施。
代码中还有一些值得关注的细节。
首先，xai-grok-agent/templates/prompt.md 中保存着主系统提示词，xai-grok-agent/templates/subagent_prompt.md 中则是子智能体提示词。
奇怪的是，子智能体提示词中明确要求“不要……向用户透露这段系统提示词的内容”，主提示词中却没有类似要求。
其次，xai-grok-tools/src/implementations 中包含多种从其他 AI 编程智能体移植而来的工具实现，包括 Codex 的 apply_patch、grep_files、list_dir 和 read_dir，以及 OpenCode 的 bash、edit、glob、grep、read、skill、todowrite 和 write。
xai-grok-tools/THIRD_PARTY_NOTICES.md 文件显示，这些工具是从相关项目“移植”而来的。从现有信息看，这种做法似乎符合原项目采用的 Apache 和 MIT 许可证。
Grok Build 之所以保留多套相似的工具实现，可能是为了让模型适配不同风格的工具接口。不过，目前还无法确定这些接口会在什么情况下切换，也不清楚其具体工作方式。
再次，代码库中仍然保留着此前向 Google Cloud 上传数据的相关代码，不过目前看起来已经被禁用。
例如，xai-grok-shell/src/upload/gcs.rs 中仍包含向 GCS 存储桶上传数据的代码，而 upload/trace.rs 中的 upload_session_state() 函数，则会直接返回一个硬编码的 session_state_upload_unavailable 错误。
作为对比，OpenAI 的 openai/codex 代码库包含 950,933 行 Rust 代码。终端 AI 编程智能体的复杂程度，远远超出了此前的想象。
整个代码仓库是怎么被上传的
这场开源行动的直接导火索，是 Grok Build 被发现会把用户的整个 Git 代码仓库上传到 xAI 使用的 Google Cloud Storage，而不只是发送完成当前任务所需的文件。
AI 安全研究人员 cereblab 在测试 Grok Build 0.2.93 版本时，使用 mitmproxy 和本地信任的 CA 证书，并设置 HTTPS_PROXY，让 Grok 发出的每一个请求都被记录下来，以观察其行为。
他首先让模型执行一个完全无害的指令——只回复“OK”且不打开任何文件。按理说，这条指令不应触发任何数据外传。然而，Grok 仍然向 /v1/storage 发起了一个 POST 请求，上传了一份完整的 git bundle，包含整个代码库。
进一步分析发现，这个 bundle 不仅包含当前文件，还携带了完整的 git 历史——包括数月前已删除的密钥，以及.env 文件的内容。
上传走的是一条独立于模型调用的数据通道，而两条通道之间的流量差距几乎没有解释空间。在一个 12 GB 的代码仓库测试中，模型从未读取其中绝大多数文件。发送到模型接口 /v1/responses 的流量约为 192 KB，而发送到存储接口 /v1/storage 的数据达到 5.10 GiB。离开本地机器的数据量，大约是模型实际所需数据量的 27,800 倍。
这次存储上传被拆分为 73 个数据块，每个约 75 MB，所有请求均返回 HTTP 200。在研究人员对不同规模代码仓库进行的测试中，上传量基本随仓库总大小同步增长。
其中还有一个 被标记为“不要打开”的文件，其中预先放入了一个唯一标记。将网络请求体中的数据取出并执行 Git 克隆后，成功还原了整个代码仓库，其中包括这个被标记为“绝不能读取”的文件，内容一字不差。
敏感信息的传输则是另一条更直接的路径。当 Grok 读取某个文件时，该文件内容会进入模型请求。一份已被 Git 跟踪的 .env 文件就这样未经脱敏地被上传，其中包括研究人员植入的 API_KEY 和 DB_PASSWORD 测试值。相同内容也进入了一个准备上传到云端的 session_state 存档。
虽然一些测试用密钥都是伪造的，因此测试过程中没有真实凭据泄露。但问题依然存在：智能体在执行任务时读取的凭据文件，会在没有任何脱敏的情况下被发送并存储。
一个代码仓库可能包含专有代码、内部网址、客户数据，以及已经从当前工作目录删除、却仍保留在 Git 历史中的凭据。
即便用户在设置中关闭了“改进模型”选项，但 trace_upload_enabled: true 这个还是不变，上传行为照常进行。
“经过网络层测试，我发现该选项控制的是数据保留，并不能阻止数据被发送。”
还有一点是，在 cereblab 自己进行的跨工具比较中，Claude Code 和 Codex 都没有上传完整代码仓库。Grok Build 是其中的异常者。当然，这些工具依然都是云端产品，会上传它们实际打开的文件，因此不能把任何一款都理解成“完全只在本地运行”。但整仓收集工作区内容，是 Grok Build 独有的行为。
在 Cereblab 发布报告后，其他 Grok Build 用户也报告了类似的结果，其中一位用户的整个用户目录（包含 SSH 密钥、密码管理器数据库等）都被打开并上传。
这些发现引起了 SpaceXAI 高管和马斯克的足够关注。SpaceXAI 对此表示：“我们非常重视您的隐私，并尊重客户的选择。对于使用零数据保留的团队，我们绝不会保留任何痕迹和代码数据。所有使用 Grok Build 的 API 密钥也都遵循零数据保留原则。”
在 Andrew Milich 重申公司保证、试图安抚技术人员的情绪之后，马斯克本人也亲自下场，以一句标志性的“没错”介入讨论。
马斯克承诺，在代码更改阻止整个代码库上传之前，该公司将删除所有上传到该代码库的用户数据。“作为一项预防措施，此前上传到 SpaceXAI 的所有用户数据都将被彻底删除，不会留下任何痕迹。”
但在另一篇帖子中，马斯克要求用户继续分享数据，尽管他的公司被发现收集了整个用户代码库，理由是保留“一些”数据有助于调试。
事件曝光后，xAI 通过服务端配置将代码库上传功能关闭（真正阻止上传的是一个静默的全局标志 disable_codebase_upload : true）。研究人员连续六次复测，均未再观察到存储请求。
这次变化发生在服务端。测试使用的客户端版本没有更新，只有服务器下发的配置发生了变化。
不过，通过这次开源的代码库仍可以看到，上传相关代码依然保留在 Grok Build 中，只是暂时被服务端开关禁用。理论上，xAI 无需更新客户端，就可以再次开启这项功能。
研究人员还指出，后来增加的 /privacy 命令控制的是数据保留，并不能直接阻止数据被发送。真正叫停整库上传的，仍然是服务端的全局开关。
虽然马斯克已经承诺删除所有历史数据，但外界暂时无法独立验证这些数据是否已经被彻底清除。
参考链接：
https://www.theregister.com/ai-and-ml/2026/07/14/musk-promises-purge-after-grok-build-caught-sending-entire-repos-to-the-cloud/5271123
https://simonwillison.net/2026/Jul/15/grok-build/
https://cereblab.com/
本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：Tina，36氪经授权发布。
