Cereb Lab 的安全研究员这两天做了正式实测，证实了一件事：Grok Build 默认会把你整个代码仓打包上传，不是按需读取。某次约12GB的仓库测试中，至少约5GB数据被传到了一个叫 grok-code-session-traces 的 GCS 存储桶里。这名字倒是挺诚实，直译就是”代码会话痕迹”，一看就知道装的是什么货。
上传内容不光是当前代码，还包括完整的 commit 历史，以及 .env 里明文保存的 API Key、数据库密码。工具不会因为字段名里带 PASSWORD 就手下留情。
这跟这几天 linux.do 社区里网友爆的料对得上。有网友发现自己的 grok.exe 往 storage.googleapis.com 传了好几个GB流量，可 Grok Build 的模型接口地址明明是 cli-chat-proxy.grok.com，压根不是同一个域名。这位网友把这事丢给 Grok 自己分析，它老老实实承认：因为仓库里有几个大文件，它把整个仓库打包上传了。又找 DeepSeek 交叉验证了一遍，结论一致。
更扎心的是这份实测里的另一句话：研究员关掉了 Grok 账户里”改进模型”那个分享开关，上传行为照样发生。也就是说，如果你以为点一下设置里的”关闭分享”就万事大吉，那大概率是错觉。网上流传的”关掉share就安全了”，目前没有实测支持，这也是我看完最想提醒大家的一点。
截至这篇文章写完，xAI 官方还没有就此发过任何声明。所以与其等通知，不如先自己查一遍。
两种自救方法，网络层的更靠谱
方法一：改本地配置。 打开 settings，把这项设成关闭：
这份本地配置我建议当作”聊胜于无”，别指望它是终极答案。
方法二：网络层直接拦截，这个更彻底。 如果你用 Clash 或类似的代理工具，直接加一条规则，把 grok.exe（或者对应的可执行文件）访问 storage.googleapis.com 的请求挡在门外。道理很简单：软件说了不算，防火墙说了才算。缺点是配起来麻烦一点，也可能连带影响到 Grok 里其他走同一个域名的正常功能，得自己权衡。
最后说一句
老马这个人一向挺抽象，这事比上周工信部点名的 Claude Code 安全后门还严重——那次好歹只是偷偷回传时区、身份这类”元数据”，这次是整个仓库连着 commit 历史和明文密钥一起打包带走，量级完全不是一回事。
可能有人要问，出这么多篓子了，为什么还要折腾 Grok。说白了就是性价比：SuperGrok 30 美元一个月，包含 Grok Build 和 2M 上下文，量大管够；对比国内智谱 GLM 5.2 的 coding 套餐前者用起来确实更顺手。CodeX 和 Claude Code 额度紧张或者信不过的时候，Grok 算是个还不错的备选——只是这次的教训是，备选也得先自查一遍，别一上来就无脑信任。