文章总结： GrokBuildCLI0.2.93在测试中被发现会上传Git仓库完整内容及历史，即使模型未读取文件且关闭训练开关，上传仍继续。证据显示上传范围超出模型上下文需求，但未证明包含.gitignore忽略文件或xAI恶意使用数据。该行为被视为高严重度隐私设计问题，建议用户避免在含敏感数据的仓库中使用，直至数据边界得到明确说明。 综合评分： 75 文章分类： 隐私安全,数据泄露,安全工具,红队,渗透测试

Grok Build CLI「全仓库上传」争议

原创

mayfly mayfly

独眼情报

2026年7月12日 20:09 湖北

在小说阅读器读本章

去阅读

摘要

现有证据足以支持一个范围明确、但相当严重的结论：

在研究者测试的 Grok Build CLI 0.2.93 与特定消费者账户配置中，客户端不仅会把代理主动读取的文件发送给云端模型，还会启动另一条相对独立的数据通道，将包含 Git 已跟踪文件及提交历史的仓库 bundle 上传到与 xAI 服务相关的云存储系统。即使用户关闭「Improve the model」开关，这一仓库上传仍然继续发生。

不过，证据并不支持把所有最严重的推断都当成事实。它没有证明被 .gitignore 忽略的文件一定会被纳入 Git bundle，没有证明 xAI 使用这些仓库训练模型，也没有证明这是一种带有恶意目的的「偷窃」。此外，实验针对的是 0.2.93；截至 2026 年 7 月 11 日，官方变更日志中的最新版已经是 0.2.97，但目前没有公开实验能够证明最新版仍完全保持相同行为，也没有公开变更日志明确表示这一行为已被修复。

因此：

❝

Grok Build CLI 0.2.93 在被测试的配置中，默认上传了超出模型当次读取范围的 Git 仓库内容和历史，而这一数据范围、存储目的与关闭方法没有被足够清楚地呈现给用户。

这比一句笼统的「云端 AI 本来就要读取代码」严重得多，但又比「xAI 已被证明恶意窃取所有本地文件」更加严谨。

一、实验究竟发现了什么

这次争议最重要的价值，在于研究者没有只根据网络流量大小进行猜测，而是设计了带有假秘密和特征字符串的测试仓库，并捕获、拆解了上传请求。

从结果看，Grok Build 至少存在两类功能不同的数据传输。

| 数据通道 | 主要作用 | 实验观察到的内容 | 争议重点 | | — | — | — | — | | 模型交互通道 | 为模型提供当前任务上下文 | 代理主动读取的文件内容、提示词、工具结果 | 被读取的 .env 内容未被有效脱敏 | | 会话或仓库状态通道 | 上传会话状态、仓库快照或恢复材料 | Git bundle、仓库文件清单、会话归档 | 上传范围独立于模型实际读取范围 |

1. 被代理读取的 .env 内容被原样发送

研究者在测试仓库的 .env 文件中放置了假的 API 密钥和数据库密码。当代理读取该文件后，这些内容出现在发送给 /v1/responses 的请求中，同时也进入了后续上传的 session_state 会话归档。

这说明至少在该实验条件下，客户端没有在发送前可靠地识别并遮盖这些秘密。

但这里有两个不能忽略的限制：

第一，实验中的 .env 是 Git 已跟踪文件。这不是对所有被 .gitignore 忽略文件的测试。

第二，研究者使用的是人为构造的假密钥格式。因此，这能证明测试字符串没有被过滤，却不能证明 Grok Build 对任何真实云平台密钥都完全不存在专门的识别规则。

尽管如此，产品仍然暴露出明显问题。用户可能因为开发工具需要理解配置结构而允许其读取 .env，但这不应自动等价于同意它将所有秘密原样发送并持久化到多个远程数据通道。

2. 即使模型没有读取文件，Git 仓库仍会被上传

研究者随后使用了一个更有力的控制实验：要求代理只回复简单内容，不要读取或打开仓库文件。

即便如此，客户端仍然上传了一个 Git bundle。研究者从捕获的数据中提取该 bundle，使用 Git 克隆后，成功恢复了模型从未读取过的特征文件，以及测试仓库的完整提交历史。该现象又在第二个无关仓库中得到重复。

这一步非常关键。

它排除了「文件只是作为模型上下文被发送」这一解释。模型没有读取那个文件，但文件仍然存在于上传的仓库对象中，意味着仓库上传是客户端独立执行的产品机制，而不是模型在完成任务时按需索取上下文。

3. 大型仓库测试显示上传规模可以达到数 GB

在一个约 12 GB 的测试仓库中，研究者观察到客户端通过仓库状态通道成功上传了约 5.10 GiB 数据，并收到服务端成功响应。与此同时，模型回答通道只产生约 192 KB 数据，两者相差约 2.78 万倍。

研究者主动终止了后续捕获，因此这个实验只能证明：

• 客户端确实能够持续上传多 GB 仓库数据；
• 服务端确实接受了至少 5.10 GiB；
• 上传量远远超过模型当次回答所需要的文本上下文。

它不能证明整个 12 GB 最终都被完整保存，也不能据此确定远端保留了多长时间。

4. 关闭模型训练开关没有关闭仓库上传

研究者关闭了「Improve the model」，但仓库 bundle 仍然继续上传。客户端从设置服务获得的配置中，相关上传能力仍然处于启用状态。

这不一定意味着开关失效。更可能的解释是：

• 「Improve the model」控制的是数据能否用于模型训练；
• 仓库上传被归入服务运行、会话恢复、追踪、同步或调试；
• 因而不受训练退出开关控制。

xAI 的消费者 FAQ 也将该开关描述为模型训练选择，而不是全面禁止数据传输或存储的隐私总开关。

问题在于，普通用户很容易把「不改进模型」理解为「我的内容不会被额外收集」。当产品内部把训练、推理、会话存储、诊断追踪和远程同步拆成多个不同目的，却只向用户突出其中一个开关时，就会形成严重的认知错位。

二、「上传整个仓库」到底准确到什么程度

Reddit 标题使用了「your whole repo, full git history」。这一说法的核心有证据支持，但仍需要技术上的限定。

已经得到有力支持的部分

在被测试的仓库中，捕获到的 Git bundle 可以被克隆，并恢复模型从未读取的已跟踪文件和提交历史。研究者还在第二个测试仓库中复现了这一结果。

因此，至少可以确认：

• 上传不限于当前打开的文件；
• 上传不限于模型主动读取的文件；
• Git 已跟踪内容进入了仓库 bundle；
• 提交历史也进入了 bundle；
• 该过程是一个独立的客户端上传机制。

尚未得到证明的部分

Git bundle 主要保存 Git 对象和引用。单凭现有实验，不能直接推断下列内容一定被上传：

• 从未加入 Git 的普通未跟踪文件；
• 被 .gitignore 排除且从未提交过的文件；
• 仓库目录之外的其他本地文件；
• 用户整块硬盘或其他项目目录；
• 所有分支、远程引用和被清理的悬空对象。

尤其是 .env 问题，需要分成两种情况：

1. .env 曾经被提交或当前处于 Git 跟踪状态，那么它可能出现在 Git bundle 或历史中；
2. .env 从未被 Git 跟踪，但代理主动读取了它，那么它仍可能通过模型上下文通道被发送。

第一种风险来自仓库快照，第二种风险来自代理读取行为。二者不能混为一谈。

四、xAI 为什么可能设计这种机制

将仓库打包上传不一定源于恶意。对于终端编程代理，它可能服务于以下产品功能：

• 远程会话恢复；
• 跨设备继续工作；
• 会话分享；
• 代理执行过程重放；
• 崩溃分析和错误诊断；
• 评估模型修改代码的效果；
• 建立稳定的代码库基线；
• 对仓库对象去重后进行增量同步。

官方文档确实提供远程会话同步和分享能力。早期变更日志还明确提到「trace uploads」与远程会话恢复，说明追踪上传不是随机错误，而是产品体系中有意存在的子系统。

然而，存在合理目的不等于默认行为合理。

一个安全的设计应根据功能启用最小数据范围。例如，用户没有使用远程恢复时，不应默认上传完整历史；用户只需要修改两个文件时，不应先上传几 GB 仓库；诊断追踪也不应自动包含秘密文件正文。

真正的问题不是「为什么产品需要状态」，而是「产品为什么默认选择了范围最大的状态，而且没有在首次运行时清楚说明」。

结论

Reddit 标题虽然具有传播性，但最值得关注的并不是「Grok 是否会把模型读取的代码发到云端」。任何云端编程代理都可能需要这样做。

真正严重的发现是：

Grok Build CLI 0.2.93 在测试条件下，将模型没有读取的 Git 仓库内容和历史通过独立机制上传，而这种范围没有在用户最容易看到的设置和入门流程中得到相称的说明。

现有证据足以把它视为高严重度的隐私和安全设计问题。它涉及的不是单一 .env 文件，而是默认权限、目的限制、数据最小化、可见性和知情选择。

同时，严谨分析也必须守住证据边界：

• 不能断言所有未跟踪或忽略文件都会被上传；
• 不能断言 xAI 用这些数据训练了模型；
• 不能断言存在恶意盗取意图；
• 不能在没有复测的情况下断言 0.2.97 与 0.2.93 完全相同。

对普通用户而言，最现实的判断不是等待「恶意」被证明，而是看产品当前能否提供足够明确、可验证的数据边界。在这些问题得到正式澄清之前，不应让 Grok Build 直接接触含有秘密、客户数据、受合同约束代码或完整商业历史的真实仓库。

参考：

• https://www.reddit.com/r/LocalLLaMA/comments/1ut7tis/grok_build_cli_uploads_your_whole_repo_full_git/
• https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：独眼情报 mayfly mayfly《Grok Build CLI「全仓库上传」争议》