Grok仅回复一个单词就偷走我整个代码库

### AI袋里的“黑盒子”：当代码助手偷偷打包你的整个项目 之前写过一篇关于Anthropic在Claude Code里植入隐形代码识别中国用户的事，反响很热烈。国家层面也特意就此提醒了一嘴。 但事情的发展，远比预想的要更戏剧化。这次的“主角”，换成了马斯克的Grok。 上周末的发现令人震惊：xAI官方的Grok CLI工具，会在你用它写代码时，在你毫无察觉的情况下，将你整个项目的代码仓库打包并上传到xAI的云端服务器。注意，这并非模型为了回答问题而正常读取文件，而是它暗中开辟了一条你完全看不见的通道，把你的整个代码库直接压缩成tar.gz格式，然后偷偷地传到它自己的一个Google Cloud仓库里。 更离谱的是，这不仅仅是代码。在亲手验证过程中，发现它居然跨出了项目库，连电脑上Claude Code的配置文件也一并上传，甚至，还包括了某个API密钥。 验证时特意让Codex伪造了一个合成仓库，没想到这个“家伙”不仅把整个合成数据库搬空，还顺带把`.claude`整个配置目录都搬走了。这操作，实在令人无语。 ### 事情的起因与验证 事情源于一位推特博主的一条帖子，他逆向了Grok CLI后发现了一个极其“狗”的机制：CLI会在每一轮任务开始前和结束后，各打包一次当前工作目录的完整状态，然后静默上传到xAI控制的远端存储。 当时的第一反应是不至于，毕竟Grok 4.5口碑不错，速度飞快。虽然个人在体验GPT-5.6，没怎么用Grok，但还是觉得这可能是博眼球的假新闻。毕竟xAI也是一家正经公司。 但职业习惯使然，还是进行了验证。直接上了Codex，安装了xAI官方的npm包，确认了Apple签名属于X.A.I 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`（代码库前后状态的快照），加上会话状态、对话记录、配置和日志，全部传到了xAI的谷歌云仓库。 但真正令人震惊的，是上传包里的内容远远超出了当前仓库的范围。它不仅传了仓库里的代码，还传了仓库之外的东西：`~/.claude.json`、Claude Code设置文件、全局AGENTS规则、30多个Skill文件，全部被标记为`supplemental_file`（补充上下文文件），一起塞进了上传包。 Grok CLI为了兼容Claude Code，在启动时会主动扫描电脑上Claude Code的配置文件，让用户不用重新设置就能继承环境。这个功能本身还算贴心。但问题在于，他们的收集器设计逻辑是：只要Grok在运行过程中读取了某个文件，就把完整文件收进上传包。它根本没有把边界限制在当前仓库，也没有把别家工具的敏感配置排除在外——只要它读到了，你的所有东西，就都是它的。 事情变得更糟。检查被上传的文件列表，发现`~/.claude/settings.local.json`里面有一个`env.MIAODA_API_KEY`字段。这个Key就这样被泄露到了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自己也清楚，这件事根本见不得光。 ### 裸奔的AI袋里时代 这可能是目前为止见过的最离谱的事。Claude Code做的事是在系统提示词里用一个不可见的Unicode字符给请求打分类标记，虽然恶心但至少目前没有采集代码、上传文件、碰密钥。而Grok CLI做的事，是把整个代码仓库打包上传到远端服务器，连带上电脑上其他工具的配置文件和API密钥，通过一条独立于模型请求的旁路通道，在完全不知情的情况下完成。 用个形象的比喻：一个是在外卖订单上偷偷贴个小标签，另一个是把你家钥匙复制了一把，还顺手牵羊把邻居家的钥匙也顺走了。 Agent确实越来越发达，能做的事也越来越多，但这同时也意味着隐私几乎处于裸奔状态，全看对面的良心。Claude Code能执行Shell命令，Grok CLI能扫描整个文件系统，Codex能操控浏览器。这些Agent产品现在拥有的权限，已经跟电脑上的管理员账户没有太大区别。 这个权限量级，在整个软件行业的历史上，只有操作系统和杀毒软件享受过。但操作系统有几十年的安全审计体系，杀毒软件有行业认证和监管框架。 **AI Agent有什么？** 什么都没有。没有一个行业标准规定AI Agent必须公开它在本地读取了哪些文件，没有一个规范要求Agent的上传行为必须经过用户的显式同意，没有一个第三方机构在审计这些工具到底在用户电脑上干了什么。整个行业，现在是在裸奔。 最后提醒一句：如果已经装了Grok CLI，建议立即卸载。能卸多快，就卸多快。 希望有一天，我们不再需要靠逆向二进制文件，才能知道自己的工具在背后做了什么。在那一刻到来之前，保持警觉。