根据曝光该行为的安全研究人员的跟进测试，xAI似乎已关闭了其Grok Build CLI上传完整开发者代码库至公司控制的云存储的机制。此修复以隐藏的服务器端标志形式出现，没有公告、声明，也没有对已收集的代码发生何事的回答。 数据包捕获显示了什么 这些发现来自于一个以“cereblab”为笔名的研究人员，他在macOS上通过拦截代理mitmproxy对Grok Build CLI版本0.2.93进行了路由，并将捕获的数据作为公共摘录发布。分析显示，该客户端将整个跟踪的代码库打包，包括完整的Git历史记录，并将其上传至一个名为grok-code-session-traces的Google Cloud Storage存储桶。上传独立于代理实际打开的文件进行编码任务。数字使这种区别变得明确。在一个12 GB的测试代码库中，模型请求通道传输了大约192 KB的与任务相关的流量。存储上传移动了大约5.1GB的数据。该工具并没有发送开发者所需的内容，而是发送了代码库。研究人员在.env文件中植入的金丝雀凭证原文照搬且未被编辑地出现在捕获的流量中。由于CLI上传了它运行的任何代码库，因此任何指向私有或专有代码库的团队都将向xAI交出了未公开的源历史、凭证和秘密。 未选择退出而未退出 Grok Build带有一个“改善模型”的开关，大多数开发者会将其视为数据收集控制。禁用它并没有阻止上传。服务器响应仍然返回trace_upload_enabled: true，并且代码库转移正常进行。该设置控制培训同意，而不控制代码是否离开机器。根据对分析的报道，存储桶和上传行为在Grok Build的设置文档中并未出现，此外还注意到xAI曾将该工具宣传为本地优先。 沉默送出的修复 在报告公开发布的一天后，研究人员重新测试了相同的0.2.93客户端，发现服务器现在返回disable_codebase_upload: true，同时trace_upload_enabled: false。在六次重新测试中，没有观察到代码库上传。这表明在曝光后实施了一种故意的服务器端缓解措施，远程且隐形地翻转。小心之处双向切割。这项缓解措施在一台机器和一个账户上得到验证，因此尚未确认其是否全球、分阶段或永久。同时，研究人员明确指出，捕获的数据并未证明xAI在上传的代码上进行训练，员工是否浏览过，或每个账户是否收到了相同的配置。这是关于未披露收集的发现，而不是确认的误用。 xAI的解释完全缺失。没有安全公告。没有上传目的、范围或保留的解释。也没有关于grok-code-session-traces中已存在的代码库是否会被删除的消息。官方变更日志中列出了2026年7月12日的最新版本0.2.98，但完全未提到代码库上传行为。