在日益激烈的 AI 竞争中，埃隆·马斯克旗下的 xAI 公司采取了一项不同寻常的举措，宣布其代码智能体 Grok Build 将完全开源，所有源代码已在 GitHub 上发布。

随之而来的是，官方取消了所有用户的服务器端使用限制，并支持完全在本地运行，不再受限于云端额度。

该项目上线后立即引起了开发者的广泛关注，短短数小时内便获得了 7.7k Star 的评价。

马斯克本人也迅速转发表示：“Grok Build 现在是开源的。”

然而，xAI 的这项开源举措也伴随着一定的争议。一方面，部分用户认为这是 xAI 迈向开放生态系统的重要一步，给予了高度赞扬；另一方面，也有网友认为，这更像是对近期隐私事件的一次补救措施，而非纯粹的“慷慨”开源。

此前，有开发者披露 Grok Build 在运行过程中会将整个用户代码库上传至 xAI 服务器，即使启用了隐私设置，这一行为依然存在，从而引发了开发者社区的广泛质疑。

Grok Build 被曝上传用户代码

与其他以 IDE 为核心的编程助手（如 Cursor、GitHub Copilot）不同，Grok Build 更接近 Anthropic 的 Claude Code 和 OpenAI 的 Codex CLI，其核心在于命令行的操作，通过 Agent 自主完成整个开发流程。

这款工具最初于 2026 年 5 月以 Beta 版本发布，定位为一款原生运行在终端的命令行开发工具。发布时，官方宣称该工具优先在用户的本地机器上运行，即“local-first”。

Grok Build 使用 Rust 编写，基于 xAI 最新的 Grok 4.5 大模型，能够直接读取本地项目代码、修改文件、执行终端命令，并调用各类工具和插件来完成复杂的开发任务，而不仅仅是回答代码问题。

Grok Build 的发布恰逢 xAI 内部动荡时期，本就自带不少关注度。但近期，其成为舆论焦点的主要原因是一名安全研究员的最新发现。

几天前，一位名为 @cereblab 的安全研究员发布了一篇题为《xAI 的 Grok Build CLI 究竟向 xAI 发送了什么？一次网络传输层分析》的长文，详细分析了 Grok Build 0.2.93 版本的网络通信行为。

通过抓包分析 Agent 的通信，他完整记录了 CLI 与 xAI 服务器之间传输的每一个数据包，试图解答两个关键问题：开发者代码中有哪些数据真正离开了本地电脑？这款主打本地运行的工具是否真的可靠？

测试结果出乎意料。

@cereblab 发现，对于普通消费者账户，xAI 官方发布的 Grok Build CLI（grok）在默认配置下会执行三项值得关注的操作：

首先，它会将读取到的文件内容，包括包含密钥的 .env 等配置文件，原封不动地发送给 xAI 服务器，且不进行任何脱敏处理。

他指出，这些敏感信息通过两条通道传输：一是发送给模型进行推理的实时请求（POST /v1/responses）；二是作为 session_state 会话归档，通过 POST /v1/storage 上传并成功存储（HTTP 200）。根据二进制程序分析，这些数据最终会被写入名为 grok-code-session-traces 的 Google Cloud Storage（GCS）存储桶。

其次，它会上传整个代码仓库，而不仅仅是 AI 实际读取过的文件。

无论 Agent 是否访问了某个文件，Grok 都会将整个工作目录打包，并通过 POST /v1/storage 上传，其中包括所有 Git 已跟踪文件的内容以及完整的 Git 提交历史。

@cereblab 通过一个真实项目进行了验证：即使在提示词中明确要求“只回复 OK，不要读取任何文件（reply OK, do not read any files）”，Grok 依然将整个仓库打包成 Git Bundle 并上传（POST /v1/storage 返回 HTTP 200）。随后，他使用 git clone 恢复了截获的 Bundle，成功找回了一个 Agent 按要求从未打开过的测试文件 src/_probe/never_read_canary.txt，其中包含的唯一标识字符串与原文件完全一致，同时还恢复出了完整的 Git 历史。

此外，@cereblab 还进一步验证了上传规模。在一个约 12GB、全部由 Agent 从未读取过的随机文件组成的测试仓库中，/v1/storage 实际传输了 5.10GiB 数据（传输过程中被截断，但所有请求均返回 HTTP 200）；相比之下，用于模型推理的 /v1/responses 通道仅传输了 192KB 数据，两者相差约 27800 倍。@cereblab 认为，这一显著差异足以证明，大规模上传的数据来源于整个代码仓库，而非模型实际读取的上下文。

值得注意的是，整个测试过程中，没有任何一次存储上传失败。唯一出现的非 200 响应，仅是 /v1/responses 接口因模型调用额度不足返回的 402/429 状态码，以及一次无关的 404 错误，而非因为上传数据过大触发的限制。

第三，上传数据的目的地是 Google Cloud Storage，而不是 AWS S3。

@cereblab 在程序二进制文件和截获的 metadata.json 中，都发现了 grok-code-session-traces 这一 Google Cloud Storage Bucket（gs://grok-code-session-traces/...）的名称。他表示，在他查阅的 CLI 安装和快速上手文档中，并未发现这一上传机制有明确说明。更重要的是，该功能默认启用，即使关闭了“Improve the model（改进模型）”选项，也不会停止上传。在测试中，/v1/settings 接口依然返回 trace_upload_enabled: true。

不过，@cereblab 最后也特别强调，以上发现并不能证明 xAI 会使用这些数据训练模型——这属于数据使用政策层面的议题，而非此次技术分析的结论。本次研究能够确认的，仅是这些数据确实被传输、服务器成功接收，并进行了存储。

这份调查报告发布之后，直接冲上了 Hacker News 的头条，并引发了大量开发者的讨论。随后，不少技术人员验证了报告的真实性，舆论矛头指向马斯克、xAI，并对这款工具的安全性表示担忧。

马斯克回应：属实

对此，马斯克出面承认——“确有此事”，随后也承诺将彻底清除相关数据。

他表示，“任何数据都不会留下（zero anything whatsoever will remain）。” 这一表态几乎没有留下任何解释空间。

根据 xAI 的说法，此前上传的所有用户数据已经被永久删除，未来也将彻底关闭数据留存机制。

回应争议，Grok Build 全面开源

当前，Grok Build 选择开源，在一定程度上也被外界视为对先前数据传输争议的回应。

近日，代码智能体 Grok Build 及其终端用户界面的完整源代码已发布至 GitHub。开发者不仅可以深入了解代码，从而理解 Agent 如何构建上下文、解析模型响应、调度工具调用等核心流程。

具体而言，此次开源涵盖了以下几个关键部分：

Agent 主循环（Agent Loop）：展示了上下文的构建方式、模型响应的解析过程以及工具调用的调度机制。 工具系统（Tools）：包括 Agent 如何读取、编辑、搜索代码，以及如何执行终端命令。 终端用户界面（Terminal UI）：涵盖了界面渲染、输入处理、执行计划（Plan）的审核，以及内联 Diff 对比查看器等功能。 扩展系统（Extension System）：包括 Skills、Plugins、Hooks、MCP Servers 和 Subagents 的加载与运行机制。

相比于仅仅开放代码，更受关注的是 Grok Build 已支持完全本地运行。开发者可以自行编译源代码，通过 config.toml 文件配置连接本地推理模型，实现整个 Agent 在本地执行。这意味着数据无需再通过 xAI 官方服务器，用户能够自主控制模型、工具调用和数据流转过程。

xAI 表示，开源是构建更强大、更可靠 Agent 框架的最直接途径。一方面，开发者可以审查代码，验证工具的实际行为；另一方面，也能够根据自身需求修改实现，构建适合团队的开发流程。

与此同时，xAI 还取消了服务器端的使用限制。过去，高频使用者容易触及官方调用额度，影响使用体验；如今，选择本地部署后，限制更多来源于用户自身的硬件性能，而非平台配额。

Grok Build 项目负责人 Andrew Milich 将其定位为一款“原生面向终端”的代码智能体。随着 Rust 代码库的全面开放，开发者不仅能够验证其实际行为，还可以按需修改底层实现，并确保所有数据始终保留在本地设备。

在整个 AI 编程领域，代码助手的竞争正日益激烈。Anthropic 的 Claude 已具备成熟的编程能力；OpenAI 的开发工具正不断融入企业工作流；Google 的 Gemini 也在积极布局开发者工具生态。各厂商都在强化模型能力和开发者生态，而 xAI 则选择以开源和本地化作为其差异化竞争方向。

对于许多开发者而言，除了模型能力本身，能够审计源码、自由修改实现，并完全掌控数据流向，同样是影响工具选型的关键因素。