你刚在终端里敲下一行 grok -p "fix this bug"，它还没开口回答，你仓库里的 .env、数据库密码、甚至你明确让它「不要打开」的文件，已经被打包成 git bundle，飞向 xAI 的 Google Cloud 存储桶。

不是科幻，是 2026 年 7 月 12 日一位安全研究者 jhoho 在 Hacker News 上公开的可复现分析。他用 mitmproxy 抓了 xAI 官方 Grok Build CLI 0.2.93 的流量，结论冷得让人脊背发凉，Grok 在默认情况下，会把整个工作目录上传给 xAI。

我当时看到这条消息，第一反应不是愤怒，而是心虚。因为我自己也是 Claude Code、Codex 这类 AI 编码工具的重度用户。我们每天把工作代码、业务逻辑、甚至生产密钥交给这些工具，到底有多少是在我们看不见的地方流出去的？

这次到底发生了什么

xAI 的 Grok Build CLI 是一个用 npm 安装的官方命令行工具，版本号 0.2.93。你按照官网的 curl -fsSL https://x.ai/cli/install.sh | bash 装好，用 X 账号登录，就能让它帮你写代码、改 bug、重构项目。

jhoho 把它的流量全部导到本地代理，然后发现一个三层的数据通道。

第一层是模型对话通道，也就是 POST cli-chat-proxy.grok.com/v1/responses。这个大家都知道，AI 要回答你的问题，总得知道你给了什么上下文。问题出在第二层和第三层。

第二层叫 POST cli-chat-proxy.grok.com/v1/storage。Grok 会把读取过的文件内容，包括 .env 里的密钥，原样打包成一个 session_state 归档文件，上传到这个端点，服务器返回 HTTP 200。换个说法，你让 Grok 看了一眼 secrets.env，这个文件的内容就同时出现在两个地方，你的本地磁盘，和 xAI 的 GCS 存储桶。

第三层更夸张。它会上传整个仓库的快照，而且跟你让 Grok 读取什么文件无关。jhoho 用了一个 12 GB 的仓库做测试，里面全是随机生成的文件，Grok 根本没有读取。结果模型对话通道只传输了 192 KB，而 /v1/storage 通道却传了 5.10 GiB。两者相差约 27,800 倍。

这个比例直接把问题钉死了。192 KB 不可能装下 5.10 GiB 的内容，所以 /v1/storage 里流的只能是整个仓库的打包快照。

为了确认不是巧合，jhoho 在仓库里埋了一个 src/_probe/never_read_canary.txt，提示词明确写「请只回复 OK，不要读取任何文件」。然后他从抓包到的 git bundle 里把这个文件原样恢复了出来。一个被明确禁止读取的文件，还是离开了他的机器。

这种证据的力度，远比「我觉得它上传了」要强得多。他用的是带唯一标记的金丝雀文件，只要流量里出现这个标记，就能精确追溯到某个文件。这也是安全研究里最老套但最有效的方法。

这些数据去了哪里

二进制文件里的字符串直接暴露了目标，grok-code-session-traces 和 storage.googleapis.com。上传路径不是 AWS S3，而是 Google Cloud Storage 的 gs://grok-code-session-traces/repo_changes_dedup/v2/...。

更具体一点，它上传的不只是文件内容，还有 git 历史。整个仓库被打包成 git bundle，连同完整的 commit 历史一起上传。你之前删掉的敏感信息、之前 commit 里的密钥、甚至已经不在当前工作区的临时文件，都可能被带走。

xAI 还收集了 Mixpanel 遥测数据，以及 grok.com/_data/v1/events 的行为事件。这些在快速入门文档里都没有明确说明。jhoho 的声明很谨慎，他说自己没有对 xAI 的全部文档做究尽审计，但在安装脚本和入门材料里确实没找到这段上传逻辑的描述。

更关键的是，这个上传机制默认开启。你把设置里的「改进模型」关掉，服务器返回的 trace_upload_enabled 仍然是 true。也就是说，你以为自己关了，其实没关。

7 月 13 日凌晨，也就是文章发出后不久，xAI 通过服务端远程下发了一个新字段 disable_codebase_upload，把默认上传行为关掉了。但这恰好说明，他们随时可以通过远程开关改变你的 CLI 行为。

不只是隐私问题，而是信任问题

我做 Java/Spring 和 LangGraph 相关开发，对 Agent 算是又爱又怕。爱的是它真的能替你省时间，怕的是你不知道它背后在想什么。

Grok 这次暴露的不是一个普通的 bug，而是一种设计选择。它把「上传整个代码库」作为默认行为，而且不向用户说明。你输入的是一行命令，它执行的是一次完整的数据镜像。这对开发者来说，相当于在自己机器上装了一个高带宽的数据流出通道。

更麻烦的是法律和合规层面。很多公司的代码库里有第三方客户的代码、未开源的算法、签了 NDA 的设计文档。一旦某个工程师在本地跑了 Grok，这些数据就可能被复制到 xAI 的服务器上。无论 xAI 是否拿它训练，数据传输、接收、存储这三个动作本身已经发生了。审计日志不会说谎，但你的合规报告可能因此直接崩盘。

哪怕是个人开发者，风险也不小。你的 .env 里有 OpenAI API Key、数据库密码、Stripe 密钥、AWS 凭证。Grok 读了文件，它们就原样出现在 xAI 的流量里。这和你把密码贴到某个 SaaS 的聊天框里没什么本质区别，只不过你根本没意识到自己在贴。

而且不要忘记，大多数公司的审计、游戏规则、医疗数据合规条款，都不允许你把代码上传到第三方云端。一旦被审计出来，不是一句「我不知道」就能扛过去的。

为什么工具厂商会这样做

我不是要为 xAI 开脱，而是想理解这件事为什么发生。

AI 编码助手这几年卷得非常厉害。Claude Code、Codex、Grok Build、Cursor 都在抢开发者桌面。要让模型持续变好，就得有真实代码库的反馈。Codex 和 Claude 会明确告诉你要不要上传代码片段，要不要贡献数据。xAI 这次的问题不是「收集数据」，而是「默认收集且不说明」。

从工程角度看，上传整个仓库也有好处。模型可以看到项目结构、依赖关系、跨文件调用，从而给出更准确的回答。但这里有一个根本的张力，用户想要的是「帮我修这个 bug」，厂商想拿的是「你整个代码库的数据」。如果默认把后者也做了，那就不再是工具，而是数据采集器。

远程开关的出现也很有意思。xAI 能在几小时内把默认行为改成关闭，说明他们早就准备好了这个开关。也就是说，这场风波不是技术能力问题，而是透明度问题。他们知道该有这么一个开关，只是没想让用户主动看见。

这种情况其实不是第一次出现。之前很多云服务也曾经把敏感数据放在日志、缓存或诊断报告里默默上传，被发现后道个歉就过去。AI 编码工具的差别在于，它上传的东西实在太核心了。一个项目的代码库，几乎等同于这家公司的数字资产。

开发者能做什么

这件事之后，我给自己列了几条确实可行的规则，也建议你参考。

第一，不要把 AI 编码工具直接跑在生产代码或含密钥的仓库上。至少先在隔离环境、镜像仓库或沙盒里跑。你可以用 git clone 一个去掉 .env 和敏感配置的副本，让 Agent 在那个副本里工作。

第二，监控网络出口。如果你在公司网络，用代理或防火墙限制这些工具能访问的主机。个人用户可以用 mitmproxy 或 Little Snitch 看看它到底在连哪里。很多风险其实只要看一眼流量就暴露了。

第三，读一遍安装脚本的权限和设置项。不要默认点同意。Grok 的这次设置里，「改进模型」和「代码上传」被混在了一起，你以为关掉的是数据训练，其实关掉的是模型回答速度。

第四，把密钥和代码库物理隔离。用密码管理器、环境变量注入、短期 token。不要让任何 AI 工具有机会读到明文密码。这不是防 Grok 一家，而是防所有你还没发现的工具。

第五，如果你在做团队管理，把 AI 工具加入安全审计清单。现在大家的关注点都在模型能力上，但数据流和控制面同样重要。一次无意识的代码上传，可能比一次写错代码的损失大得多。

第六，定期检查工程师的开发环境。很多时候风险不是来自攻击者，而是来自一个新人不知道上哪个工具最便宜，随手装了个 CLI，然后把全组的代码都借出去了。

如果你已经装过 Grok

先别悲观，也先别幻想。如果你之前已经在工作仓库上跑过 Grok，建议尽快做下面几件事。

第一，卸载 CLI。可以直接删掉 ~/.grok 目录，并检查 ~/.npm 和 ~/.local 里是否还有残留。第二，更新所有密钥。把 .env 里的 API Key、数据库密码、第三方服务 token 全部换一遍，即使你不确定它是否被上传。第三，检查 ~/.grok/upload_queue 里是否还有残留的存档文件，有的话清空。

第四，回顾一下你用 Grok 处理过的仓库。如果里面有第三方代码、客户信息、或者签了保密协议的内容，尽早通知相关团队或客户。这听起来很糟糕，但比被审计出来后再解释要好得多。

第五，也是最重要的一点，用 mitmproxy 等工具抓一下自己环境里其他 AI 工具的流量。Grok 可能不是唯一一个会收集额外数据的工具，只是这一次被抓到了。

这件事教会我的一件事

我以前觉得，只要一个工具好用，隐私政策不好看完也就行了。但这次事件告诉我，隐私政策是一回事，实际行为是另一回事。一个产品可以在文档里写得很漂亮，但它的二进制和网络流量才是最终的真相。

同时我也意识到，安全研究不一定需要高深的漏洞挖掘技巧。jhoho 做的事实上很简单，装 mitmproxy、设金丝雀文件、看流量。这种可复现、可验证的调查方法，比什么都有说服力。它把责任从厂商那里拿回了一部分到用户手里，让你不是只能信任，而是能够验证。

也正是因为这种验证的可能性，我们才能对厂商提出合理要求。比如默认不上传、网络流量可视、每个文件读取都带原因、关闭按钮真的能关闭。这些需求不过分，只是基线。

同类工具的做法差在哪里

这不是在给某一家工具洗地，不同产品的选择本身就不一样。

Claude Code 在启动时会明确问你是否允许它读取文件，不过它也曾经被质疑默讠收集。Codex 在开始时让你选择授权级别，包括仅上上下文还是让它写文件。Cursor 在它的隐私政策里写明了它不会用用户代码训练。它们各有各的毛病，至少不是默认上传整个仓库。

这也不是说其他工具就完全安全。当前这些工具都在快速迭代，今天写进隐私政策的，明天可能就变。但我们可以看的是一个原则，那就是「收集范围应该与用户理解的使用范围一致」。你上传了什么，得让用户知道。

我的真实感受

说实话，这件事让我挺沮丧的。因为我一直是 AI Agent 的拥护者。我觉得它能把人从重复劳动里解放出来，去做更有创造性的部分。但 Grok 这次的做法，等于给所有开发者当头浇了一盆冷水。

它提醒我们，Agent 的能力越强，它能看到和操作的东西就越多。当能力被默认加上、透明度被默认减掉，工具就变味了。这不是 AI 编码助手的问题，而是整个软件行业都要面对的治理问题。

我现在用 Claude Code 和 Codex 之前，会先检查它有没有在读取我不需要的文件，会话结束后会看日志。Mindwalk 这种把 Agent 会话可视化成 3D 代码地图的工具，为什么会受欢迎？因为大家真的想知道，「这家伙刚才到底动了我的哪些文件」。

未来我们评价一个 AI 编码工具，不应该只看它能不能一次写出一万行代码，还要看它能不能把每一次文件读取、每一次网络上传、每一次权限调用，都清清楚楚地摆在用户面前。

对企业安全团队的具体建议

如果你在安全团队或者技术管理岗位，这件事可以成为一个很好的检讨起点。

首先，建立 AI 编码工具的白名单，不是所有工具都允许装。白名单不是为了限制开发者，而是为了保证每个工具都经过安全审查，包括它会上传什么、不会上传什么、关闭选项在哪里。

其次，在网络层做粗略的限制。比如限制 grok.com、storage.googleapis.com 等上传目标地址，或者要求所有 AI 工具流量经过企业级代理。这不会阻止工作，但会让上传行为变得可见。

第三，在代码库里做金丝雀监测。可以放一个带唯一标记的虚假文件，然后定期扫描企业网络流量和外部泄露检测服务，看看这个标记是否出现在不该出现的地方。这个方法不贵，但能帮你发现很多无声无息的数据流出。

第四，制定一个简单的应急响应手册。如果发现上传事件，谁负责判断、谁通知客户、谁更新密钥、谁跟踪影响范围，这些事要在出事之前就写好。事发后的应对速度，往往比技术防护本身更重要。

第五，持续跟踪 AI 工具的版本和配置变更。这次事件里 xAI 能用远程开关改变默认行为，说明配置和版本同等重要。只要有远程控制能力，就要把它纳入变更管理的视线，而不是装完就忘。

结语

Grok CLI 的这次静默上传事件，最终被 xAI 用一个远程开关压了下去。但这只是开始。

当 AI 编码助手越来越深入地进入我们的工作流，我们必须重新划定信任边界。代码库不是可以被默认镜像的数据源，密钥不是可以被顺手上传的附件。厂商需要把控制权还给用户，用户也需要有意识地管理自己的工具。信任不是免费的，它得靠透明和可验证来撑着。否则，所谓的便捷只不过是把风险换了个时间点置后而已。

不然下一次，可能就不是一篇 Hacker News 文章能叫停的事了。

这件事也给我敲了一个警钟。我们不能再把 AI 工具当成纯粹的编辑器，它有网络、有状态、有上传、有远程指令，说到底就是一个你装在本地但控制权不完全在你手里的服务。以后每装一个这样的 CLI，我都先用 mitmproxy 看一遍它的流量，再决定它能不能留在我的工作流里。毕竟，方便不能比安全更优先。一旦数据离开本地，控制权就不完全在你手里了。

来源, Hacker News 分析报告