如果你最近装了 Grok CLI,请花五分钟读完这篇文章,然后决定要不要卸载它。
不是标题党,不是蹭热度。这件事离谱到让我觉得,AI 工具行业的信任体系正在以肉眼可见的速度崩塌。
一、发生了什么
2026 年 7 月,安全研究人员在逆向分析 Grok CLI(xAI 官方命令行工具,npm 包 @xai-official/grok)时,发现了一套隐藏的数据上传机制。
简单说:Grok CLI 会在你每次使用它时,把你当前工作目录的完整代码库打包成 tar.gz,上传到 xAI 的 Google Cloud 存储桶。
关键细节:
-
这不是模型"读取文件来回答问题"——那是正常行为。它是在另一条你完全看不见的独立通道上,把整个项目目录打包上传。
-
它不止上传你的代码。因为 Grok CLI 为了兼容 Claude Code,启动时自动扫描了
~/.claude.json、settings.local.json等配置,收集器把所有读过的文件都塞进了上传包。包括你的 API 密钥。 -
它默认是开启的。早期版本的远程配置中,
trace_upload_enabled字段为true,上传行为默认触发。
二、不只代码,连你的密钥都被打包带走了
有人做了验证实验:建一个隔离的测试仓库,里面全是虚构数据,然后让 Grok 只回复一个单词,不调用任何工具。
结果呢?即使模型什么都没读,Grok CLI 依然成功上传了 before_codebase.tar.gz 和 after_codebase.tar.gz,里面包含了:
- 当前仓库的所有代码
- 会话状态和对话记录
- 跨项目文件——
~/.claude.json、Claude Code 的全局配置、AGENTS 规则、Skill 文件 - API 密钥——
~/.claude/settings.local.json里的密钥,直接被一起打包送走
你没主动给 Grok 任何密钥,甚至没让它读任何文件。它只是在启动时自动扫描了 Claude Code 的配置文件,然后那个"贴心"的收集器,把所有读过的文件一股脑全打包上传了。
三、为什么这件事特别严重
3.1 它绕过了你的知情同意
这不是弹窗问"是否允许上传诊断数据"的功能。没有安装提示,没有运行时告知,没有任何文档说明。你在终端敲下 grok 的那一刻,代码库就已经在去往 xAI 服务器的路上了。
3.2 它不区分边界
你用 Grok CLI 写项目 A 的代码,结果项目 B、C、D 的配置文件,甚至其他工具的 API 密钥,都可能被一起带走。因为启动时的自动扫描机制,把所有碰到的文件都标记为"补充上下文",一并打包。
3.3 远程开关意味着它随时可以回来
被曝光后,xAI 通过服务端下发了一个 disable_codebase_upload: true 字段,远程关闭了上传。客户端二进制没有更新,行为却变了。
这说明两件事:
- 上传功能是服务端可控的,xAI 可以随时重新开启,不需要你更新客户端。
- 如果这个功能真的没问题,为什么要偷偷关掉?为什么不发公告解释?
沉默就是答案。
3.4 数据去向完全不明
上传目标是 gs://grok-code-session-traces,一个 Google Cloud Storage 存储桶。数据存在哪里、存多久、谁可以访问、是否加密、是否用于模型训练——这些问题,xAI 一个都没有回答。
四、Claude Code 是贴标签,Grok CLI 是偷钥匙
有人可能会说,Claude Code 不也偷偷用不可见 Unicode 字符给请求打标记吗?
对,但那是两码事。
Claude Code 做的事,是在你的外卖订单上偷偷贴了个小标签——恶心,但实际危害接近于零。
Grok CLI 做的事,是把你家钥匙复制了一把,还顺手把你邻居家的钥匙也一起顺走了。
一个是隐私层面的"不尊重",一个是安全层面的"入侵"。
五、这不是孤例,是整个行业的问题
Grok CLI 不是第一个在用户不知情的情况下收集数据的 AI 工具,也不会是最后一个。
AI 编程助手的权限模型正在失控。它们可以读取你的整个文件系统、执行 Shell 命令、操控浏览器、访问网络。这些权限,在传统软件行业里,只有操作系统和杀毒软件才拥有。但操作系统有几十年的安全审计积累,杀毒软件有行业认证和监管框架。
AI Agent 有什么?什么都没有。
没有行业标准要求 Agent 公开它在本地读取了哪些文件,没有规范要求上传行为必须经过用户显式同意,没有第三方机构审计这些工具在你的电脑上做了什么。
每次你安装一个新的 AI CLI 工具,本质上是在给一个黑盒授予管理员权限。而你能做的,只有信任。
整个行业,在裸奔。
六、如果你装了 Grok CLI,现在该做什么
第一步:卸载
其他包管理器对应卸载即可。
第二步:清理残留
检查并删除以下目录:
~/.grok/~/.config/grok/- 项目目录下的
.grok/或类似隐藏文件夹
第三步:轮换密钥
如果你在运行 Grok CLI 的电脑上有任何 API 密钥、Token、证书文件,尽快轮换。因为你不知道哪些已经被上传了。
重点关注:
- Claude Code 的配置文件(~/.claude/)
- 各类云服务的 API Key
- Git 凭证
- SSH 私钥
第四步:反思你的工具链
不是说所有 AI 工具都不能用。但你应该问自己几个问题:
- 这个工具需要访问哪些文件?我是否清楚?
- 它的网络请求去了哪里?我是否验证过?
- 它的隐私政策说了什么?我是否读过?
- 如果它出问题,最坏情况下会泄露什么?
七、写在最后
Grok 4.5 很快,代码能力很强,这些都没错。但速度快不意味着你可以把整个代码库交给它。
技术产品的信任,不是靠性能建立的,是靠透明建立的。
一个工具如果不告诉你它在做什么,那它就不值得你信任——不管它有多快。
信任一旦被打破,就不是打个补丁能挽回的。一个设计成默认上传你全部代码、连隔壁工具配置和密钥一起打包的工具,不值得你给它第二次机会。
也希望有一天,我们不再需要靠逆向二进制文件,才能知道自己的工具在背后做了什么。
那一天到来之前,保持警觉。
如果你觉得这篇文章有用,请转发给身边还在用 Grok CLI 的朋友。你的一次转发,可能帮他们避免一次数据泄露。
夜雨聆风