Grok CLI 被曝默认上传全部本地文件至云端，含密钥和 git 历史

你好，我是Gergely，附赠一期《实用工程师通讯》免费刊物。每期杂志，我都会从高级工程师和工程领导者的视角报道大型科技和初创企业。

今天，我们将涵盖以下四个主题中的一个之前的The Pulse问题。全额订阅者四周前收到了以下文章。如果你已经收到这封邮件，你可以点击此处订阅.

上周，xAI（埃隆·马斯克的人工智能公司，现为SpaceX一部分）发布了Grok 4.5型号，由Cursor（收购）制造，训练基于SpaceX显卡，品牌名为“Grok”。

这是一个相当不错的模型;在编码能力上与Opus 4.8和GPT 5.5相当，且成本降低60%-70%。

Grok 4.5 可以通过 API 使用，但通过 Grok Build 编码 CLI 使用最方便。所以，很多开发者都是这么做的。他们中有些人注意到了一些事情真的奇怪的是：CLI竟然把他们所有的本地文件上传到工作目录里！

这里有一位独立的人工智能安全研究员，名为“Cerblab”记录正在发生的事情（重点是我加的）：

“xAI 官方的 Grok Build 代码 CLI（grok）在普通消费者登录时，能精确记录三项内容：它会将读取的文件内容——包括一个 .env 秘密文件——逐字且未删减地传输给 xAI。.该秘密出现在两个通道中：实时模型转折（POST /v1/responses）和通过POST /v1/storage上传并接受的session_state归档（HTTP 200）——该终端是二进制路由到grok-code-session-traces GCS桶的终端（见第5节）。它会上传整个仓库——每个被追踪文件的内容以及 git 历史——与代理读取的内容无关。Grok 打包工作区并通过 POST /v1/storage 上传。直接验证：在真实代码库中，Grok 以“回复 OK，勿读取任何文件”为提示，将整个仓库上传为 git bundle（POST /v1/storage → 200）;Git 克隆捕获的捆绑包会恢复代理被告知不要打开的文件——src/_probe/never_read_canary.txt——并附录其唯一标记，以及完整的 Git 历史（附录 uploaded_repo.bundle）。而且它是可扩展的：在一个12GB的未读取随机文件仓库中，/v1/storage移动了5.10 GiB，全部是HTTP 200（中间截断），而模型转向通道仅移动了192 KB——约27,800×的比例将上传钉在代码库上，而非读取数据。没有存储上传失败;唯一非200的是在/v1/responses上的型号使用配额（402/429）和一个无关的404——不是存储容量上限。存储目标是 Google Cloud Storage 桶，grok-code-session-traces（非AWS S3）——在二进制和捕获metadata.json中逐字命名（gs://grok-code-session-traces/...）。我在CLI的安装/快速启动材料中没有看到这个机制（不是详尽文档审核——§7），默认是激活的，禁用“改进模型”也不会关闭它（/v1/settings 仍然返回 trace_upload_enabled： true;§6）。

这些都不能证明xAI会基于数据进行训练——这是[第6节]中讨论的政策问题。被证明的是传递、接受和存储。”

这种做法有很多问题！举几个例子：

• 通过上下文窗口发送代码库是不正常的。所有 AI 代理都会把他们的上下文窗口发送给运行 LLM 的服务器。代币化就是在那里进行的，上下文会附加到会话上。这意味着其他AI代理会发送他们在上下文窗口中读取的部分代码。
• 不需要发送源代码来索引。索引代码库对于高效的代码查找非常重要，我们介绍了Cursor如何以注重隐私的方式做到这一点通过本地索引用户代码库，创建嵌入，并将这些嵌入发送到服务器。不过光标服务器不会存储用户的任何代码库。但Grok CLI把所有用户的代码库都转移到了一个云桶里！鉴于Cursor和Grok现在合并为SpaceX的一部分，Grok CLI为何不像Cursor那样运作，真让人费解。
• 发送未加密的.env文件是鲁莽的。本地 .env 文件存储秘密、数据库访问令牌、服务访问令牌等。这些都是需要谨慎处理的敏感信息。如果传输，至少应该加密。Grok / SpaceX 将这些数据存储在 GCP 存储桶中——很可能是未加密的——完全不可接受，这足以让任何理智公司禁止使用 Grok CLI 的理由。
• 没有理由上传git历史记录。当然，看到Git历史在训练AI模型时可能会有帮助。
• 不告诉开发者任何信息是恶意的。使用 Grok CLI 的开发者未被要求选择是否参与此次数据上传，也未被通知相关信息。大多数显然完全不知道这件事正在发生，Cerblab的报道走红后他们理所当然地愤怒不已。

SpaceX 把开发者“推下了火坑”

当场被抓获后，Grok CLI 禁用了带有远程功能标志的文件上传。AWS工程师韦斯·埃克伦德开始追踪上传功能时发现上传突然停止，原因是Grok团队反转了一个功能标志，暂停了数据收集。

但将所有本地文件未加密流向服务器的代码功能仍然保留在 CLI 中，即使在后续更新中也是如此。读一读韦斯的深入分析。

SpaceX的官方回复相当可笑，没有解释为什么要上传.env文件和.git历史记录，并补充说，只有启用零数据保留（ZDR）的企业客户才是没有受到用户本地文件秘密上传影响的：

我最初的反应是，SpaceX的回答居高临下，紧接着是：Grok CLI真的有企业客户吗？考虑到团队上传未加密秘密的鲁莽行为，可能并不多！

SpaceX首席执行官埃隆·马斯克发表了一篇似乎是在嘲讽愤怒用户的帖子。他写道:

“SpaceX关于数据保留的政策。

如果能保留一定量的数据，这对调试问题很有帮助，所以允许这样做会很感激，但你的隐私设置始终会被尊重。”

这让情况更糟，因为SpaceX秘密上传的数据远远超过“调试用”的水平！上传git历史和敏感的.env文件是不是，任何对调试有用的方式。此外，Grok/SpaceX并未上传“一定量的数据”;它上传了你本地文件夹里能找到的所有文件。

开发者社区对SpaceX和Musk假装Grok只是上传零碎数据纯粹用于调试感到有理有据。这一次，连SpaceX和Grok的粉丝也开始公开反对马斯克及其公司的行为。

AWS工程师韦斯·埃克伦德:

“埃隆，首先，我非常喜欢你所有的工作。完全理解需要一些跟踪数据来提升客户体验。

根据我查到的资料，问题似乎远不止是跟踪调试的问题。看起来是整个代码仓库，里面收集了全部敏感信息。

你的Google Cloud大块存储必须包含我们提供的PB级代码仓库。

这并不理想。”

Sam Altman 将 Grok 推向开源 Grok CLI

OpenAI的CEO Sam Altman也发帖，使用了马斯克常用的术语来评论他不赞同社会中的事物，并暗示Codex的好处，因为它不会上传整个本地文件系统，也不会干扰.env文件和git历史。

Codex 线带是开源的，因此在源代码中可以看到隐秘的文件上传功能：

马斯克显然读了这封信，并在几个小时后回复了：

一天后（7月15日），SpaceX确实做到了开源Grok CLI。奥特曼的评论似乎打动了我。此外，SpaceX表示正在删除服务器上的数据，写作:

“我们从7月12日起禁用了所有Grok Build用户的默认保留。此外，我们正在删除所有之前保留的编码数据，确保尊重每位用户的偏好。通过这些步骤，Grok Build 超越了其他主要编码产品，保护用户隐私。”

开源仓库的开发很仓促，这不足为奇。内核工程师Elliot Arledge使用了该仓库并报告了他发现:

“开箱即用，'货物测试--工作区'不会编译。190+ 错误，全部为一个 bug 类：隐藏在 #[cfg（test）] 之后的跨箱测试助手，Bazel 的每个目标测试构建能容忍，但 Cargo 不能，因为测试模式下从不编译依赖。默认表盘功能在 ~20 个清单中声明，并且接线到无任何东西。取消无害的辅助工具，并将签名密钥测试接缝放在仅依赖开发者依赖的功能后面，使套件首次在发布的树上运行：24,663 个通过，28 个失败，这 28 个都是 broced build 隐藏的既存 bug（测试读取你的真实 ~/.claude/settings.json，注册表中缺少的工具， macOS /var symlink breakage，一个 Theme：：current（） race）。

给团队的问题：

有人尝试下载这个仓库并在发布前运行过吗？”

公平地说，从外部来看，开发团队被指示尽快开源仓库，并且确实这么做了。我预计开发者社区会有改进，以便编译仓库并运行测试。

顺便说一句，我很好奇Grok内部的氛围是什么。一个开源产品——而这个产品本来就不是为开源而设计的！——而且在几个小时内完成，暗示了在那里工作的感受。

有些人无疑会觉得这既刺激又充满挑战，而另一些人则可能觉得被“索伦之眼”（CEO）压制会非常有压力！

公司现在能信任Grok吗？

说句话，Grok/SpaceX在这次事件的最后24小时里，执行得非常出色。相比之下，之前发生的一切让人觉得“业余时间”：

• 难道团队里没有人写过上传完整本地代码库的功能时，担心开发者会不能接受这种做法吗？
• 为什么上传没有加密的秘密不会引起警觉？
• 为什么要在没有同意同意的情况下，以秘密方式批准任何项目？

对于通过软件创造收入的理智公司来说，允许访问其代码库的供应商只能信任。Grok 已经证明它没有准备好以安全基础为核心来处理代码库。

现在出现了疯狂的退缩和快速的开源，但我的印象是，这仅仅是因为Grok/SpaceX被当场抓住了，并且明白这种公然违信可能导致的企业合同丢失风险。

这也是为什么SpaceX的沟通提到，零数据保留的企业客户并未受到影响！

信任以滴落的形式获得，以桶状方式流失;SpaceX/Grok很可能会学到这一点。通过秘密上传代码库和秘密代码，Grok CLI 暴露了自己是一个不可信的编码代理，使用起来有风险。

与此同时，所有主要竞争对手——Claude Code、Codex、OpenCode、Gemini CLI——从未以这种方式破坏用户信任。

Grok CLI 可以重建信任，但要证明他们是开源优先的产品（就在一天前还不是！），并且要证明他们关心“普通”开发者，而不仅仅是开启 ZDR 的企业客户端，可能还需要多年无安全相关事件。

这一事件很好地提醒我们，规划和流程可能会拖慢运输速度，但却能增加收入增长。我敢打赌，Grok团队在可预见的时间内已经缩减了SpaceX的企业订阅前景，目的是节省几个小时的安全审查时间，学习其他编码工具如何处理代码库上传，甚至只是向Cursor团队请教！

我预测Grok/SpaceX必须在Grok CLI内设定非常高的使用限制，才能说服开发者冒险在他们的系统上运行这款软件。而且，他们必须大幅压低OpenAI和Anthropic API的价格，任何安全团队才能批准使用上周还在向GCP桶发送未加密.env秘密的CLI使用。

当然，SpaceX/Grok会没问题，因为他们有资金修复问题。现在修复这些问题会变得更加昂贵和耗时，而这些问题很可能是少数工程师为了简化调试而导致的！

请阅读完整《脉搏》期刊，或者去看看本周的《脉动》.整期还涵盖了：

1. 新趋势：代码审查负担大幅增加的担忧。工程领导者最关心的问题是：如何应对日益增长的代码审查负担，以及开发者如何开始比以前更不彻底地审查代码？问题很多，但很少有被证实的解决方案。请评论你认为有效的方法。
2. 是否有更多企业开发者对AI实验室的企业定价感到不满——这重要吗？我收到一位读者的信息，感到困惑的是，他们公司支付的代币价格是他们每月20美元的Claude Code / Codex订阅费的20-30倍。这可能会显示AI编码工具的价值。
3. Linux创造者：人工智能“显然有用”。在Linux内核维护者小组内部，讨论转向了Linux是否应考虑禁止AI贡献，类似于一些自由开源软件项目所做的那样。Linus Torvalds发表了看法，明确表示人工智能有用，每个人都应该决定是否使用它，但没有人被允许告诉别人该用什么工具。鉴于人工智能越来越强大，不将其作为工具使用将是愚蠢的。

阅读全文《脉搏》