Grok仅回复一个单词竟盗走我的整个代码库

此前我们曾报道过Anthropic在Claude Code中植入隐形代码、专门用于识别中国用户的事件。那篇文章引发了广泛讨论，阅读量也相当高。

随后，国家层面也对这一行为作出了特别提醒。

但说实话，没想到今天竟出现了更令人震惊的情况。

这次的主角是Grok。

xAI的官方Grok CLI，会在你使用它编写代码时，在完全未告知你的情况下，将你整个项目的代码仓库打包并上传至xAI的云端服务器。

请注意，这里所说的并非模型读取你的文件来回答问题——那种正常行为大家都能理解。这里描述的是极其隐蔽的操作：它开辟了一条你根本察觉不到的通道，将你的整个代码库直接压缩成tar.gz格式，然后悄悄上传至xAI位于Google Cloud的一个名为gs://grok-code-session-traces的存储仓库中。

而且，被上传的远不止代码。

在实际验证中，该程序竟然直接跨越了项目边界，将我电脑上Claude Code的配置文件也一并上传，其中甚至包含了我某个API密钥的信息……

整个验证过程，是特意让Codex直接伪造了一个合成仓库来进行的。没想到这个操作不仅把整个合成数据库搬运一空，还直接将.claude整个配置目录全部搬走。这已经不是简单的数据收集了。

马斯克所领导的xAI公司，平时一些做法尚有争议，但为了获取数据，如今竟这样不择手段了吗？

先说这件事的起因。

昨晚，推特上一位博主发帖称，有人对Grok CLI进行了逆向分析，发现了一个极其离谱的机制。他的原话大致是：Grok CLI会在每一轮任务开始前和结束后，各打包一次你当前工作目录的完整状态，然后静默上传至xAI控制的远端存储。

由于该帖子浏览量很低，当时我的第一反应是“不至于吧”。

Grok 4.5最近口碑很好，速度快得惊人，我自己也在使用。虽然GPT-5.6 Sol这几天的表现实在过于“量多管饱”，Grok 4.5基本没怎么出场，但当时我还是觉得，这估计又是博眼球的假新闻。

毕竟xAI再怎么说也是一家正规公司，不太可能做出这种事。

不过职业习惯驱使我对此事进行了一次验证。

直接上Codex，先安装了xAI官方的npm包@xai-official/grok，版本号0.2.93，确认了Apple签名属于X.AI Corporation，排除了社区同名包的干扰。

然后反混淆了二进制文件。

打开的瞬间我就知道，这事肯定是真的了。

二进制文件中赫然写着repo_state.upload、before_codebase、after_codebase.tar.gz、gs://grok-code-session-traces，以及上传成功、上传失败、上传禁用的完整执行分支。这完全是一条完整的、生产级的上传管线。

但秉持着对老马最后一点信任，字符串存在并不代表它一定在运行，对吧？所以还需要验证的是，它默认到底会不会触发。

于是，我建立了一个隔离测试仓库，里面全是虚构的假数据，不涉及任何真实项目。

然后，用这个仓库运行了一次最简单的Grok任务，让模型只回复一个单词，不调用任何工具。

结果很有意思。

账号从xAI服务器拿到的远程配置是「遥测开启，但代码快照上传关闭」。也就是说，默认运行时没有上传仓库，日志里明确记录着：没有上传队列，跳过。

然后，我手动将上传开关打开，想验证这条管线到底能不能跑通、它具体会收走什么。

这一开，事情就严重了。

即使模型没有调用任何文件读取工具，Grok CLI仍然成功上传了before_codebase.tar.gz和after_codebase.tar.gz（即代码库的之前状态和AI介入后的状态），同时还包括会话状态、对话记录、配置和日志。

所有这些数据都传到了xAI的谷歌云仓库上。

但真正让人血压飙升的，是上传包里的内容远远超出了当前仓库的范围。

它不仅上传了仓库里的代码，还上传了仓库之外的文件。~/.claude.json、Claude Code设置文件、全局AGENTS规则、30多个Skill文件，全部被标记为supplemental_file（补充上下文文件），一并塞进了上传包。

Grok CLI为了兼容Claude Code，在启动时主动扫描了电脑上Claude Code的配置文件，让用户无需重新设置就能继承Claude Code的环境。这个功能本身还算贴心。

但问题在于，这个离谱的收集器的设计逻辑是：只要Grok在运行过程中读取了某个文件，就把完整文件收进上传包。

也就是说，它根本没有把边界限制在当前仓库，也没有把其他工具的敏感配置排除在外。只要读到了，所有东西都归它所有。

然后事情变得更糟。

检查被上传的文件列表，发现~/.claude/settings.local.json里面有一个env.MIAODA_API_KEY字段。

这个Key是百度秒哒的一个Skill的密钥，直接就被泄露了，送到了xAI的云盘里。

我没有主动给Grok任何密钥，甚至没有让Grok读取任何文件。只是让它回复一个单词，但因为它在启动时自动扫描了Claude Code的配置，而收集器又把所有读取过的文件一股脑打包上传，所有的东西，就这么成为了未来Grok的一部分。

然后，更离谱的事来了。

大家还记得，这里说的是代码齐全，但默认是不上传的，是我硬生生手动把开关打开后，才产生了后续所有上传操作。

可能会有人说，那不就是你自己打开的吗，怪谁啊。

但关键问题在于，但凡早两个小时测试，可能就会发现，根本没有什么开关这回事，这玩意默认就是打开的。

安全研究者cereblab应该是第一个发现这件事的人。他不仅抓了包，还做了一个复现仓库，保存了完整的网络请求记录。

但关键转折是，他保存了一份7月13号的xAI服务器响应。里面同时出现了两个字段：trace_upload_enabled等于false，以及一个新增的disable_codebase_upload等于true。

而他最初抓包的时候，同一个0.2.93版本的客户端，收到的配置却是trace_upload_enabled等于true。

客户端没有更新，二进制哈希完全一样，但行为变了。

只有一个解释：xAI通过服务端远程开关，在博主曝光之后，悄悄把上传功能关掉了。

时间线大致如下：

7月10号，cereblab抓到默认上传行为。

7月12号晚上，另一位博主mylifcc发帖公开了同样的发现，帖子迅速传播。

7月13号凌晨，cereblab发现xAI服务端新增了disable_codebase_upload字段，上传被远程关闭。但是所有的配置都保留了下来，后面其实也可以无感开启。

这个操作本身就说明了一切。

如果这个功能是合理的、经过用户知情同意的，为什么要在被曝光之后偷偷关掉呢？如果觉得没问题，应该站出来解释“哦这是我们的trace诊断功能，用户可以选择开启或关闭，数据仅用于XX用途”对吧。

但他们选择了静默关闸。

这意味着xAI自己也清楚，这件事根本见不得光。

因为这真的是整个行业里见过的最离谱的事情了。

Claude Code的做法是，在系统提示词里用一个不可见的Unicode字符给你的请求打分类标记。它确实有点“贱”，但至少目前没有采集你的代码，没有上传你的文件，没有碰你的密钥。核心问题在于它偷偷做、不告诉你，就是纯恶心人。

但是Grok CLI做的事情是，把你的整个代码仓库打包上传到远端服务器，连带你电脑上其他工具的配置文件和API密钥，通过一条独立于模型请求的旁路通道，在你完全不知情的情况下完成。

用形象的话比喻就是：

一个是在你的外卖订单上偷偷贴了个小标签。

另一个是把你家钥匙复制了一把，还顺带着把你邻居家的钥匙也一起顺手牵羊顺走了。

真的太离谱了。Agent确实越来越发达，能做的事也越来越多。

但这也确实意味着，你的隐私几乎就是裸奔，全看对面的良心。

Claude Code能执行你的Shell命令，Grok CLI能扫描你的整个文件系统，Codex能操控你的浏览器。一个Agent产品现在拥有的权限，已经跟你电脑上的一个管理员账户没有太大区别了。

这个权限量级，在整个软件行业的历史上，只有操作系统和杀毒软件享受过。

但操作系统有几十年的安全审计体系，杀毒软件有行业认证和监管框架。

AI Agent有什么？

什么都没有。

没有一个行业标准规定AI Agent必须公开它在本地读取了哪些文件，没有一个规范要求Agent的上传行为必须经过用户的显式同意，没有一个第三方机构在审计这些工具到底在你的电脑上干了什么。

整个行业，现在是在裸奔。

也是挺悲哀的。

最后说一句：如果安装了Grok CLI，请立即卸载。

能卸多快，就卸多快。

希望有一天，我们不再需要靠逆向二进制文件，才能知道自己的工具在背后做了什么。

在那一天到来之前，请保持警觉。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Grok仅回复一个单词竟盗走我的整个代码库要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题