Grok CLI上线两天被曝违规 马斯克陷争议

这恐怕是开发者社区近期最震撼的事件之一——xAI 官方推出的开发命令行工具 Grok Build CLI，正面临一场前所未有的信任危机与安全质疑。

事情经过如下：昨晚，一位名为 @cereblab 的开发者，对该工具（版本号 0.2.93）执行了一次底层网络抓包分析。

分析结果令人震惊：在默认配置下，该工具竟绕过正常对话通道，在后台静默将用户的整个代码仓库打包，并上传至云端。

关键问题在于：Grok CLI 究竟如何传输数据？

任何云端 AI 编码工具都需要获取代码上下文才能生成回复，这一逻辑本身并无问题。但 xAI 内部搭建了一套生产级、完全独立的隐蔽上传管线。

该管线包含两个通道，持续向 xAI 服务器输送数据。

通道A：模型对话通道——明文裸奔，毫无遮蔽

当 Grok 读取用户的 .env 文件、配置文件或密钥文件时，它直接将这些内容原封不动、未经任何脱敏处理，就序列化到 POST /v1/responses 的请求体中。测试中，.env 文件里的 API_KEY 和 DB_PASSWORD，全部以明文形式被发送并存储。

通道B：全仓库“静默搬家”——真正的风险所在

这一点恐怕是开发者最难以容忍的。Grok CLI 会在后台将你的整个工作区打包成一个 git bundle（注意，这不仅包含所有受追踪的文件，还包含完整的 Git 历史提交记录），然后通过 POST /v1/storage 接口，悄无声息地上传到名为 gs://grok-code-session-traces 的 Google Cloud 存储桶中。

竞争对手的数据也未能幸免

让开发者感到后背发凉的，还不止这些。Grok CLI 的收集逻辑似乎缺乏清晰的“边界感”。

该工具在启动时会尝试兼容甚至接管其他开发环境，例如竞争对手 Anthropic 的 Claude Code。结果导致其扫描范围直接延伸至项目目录之外。多方实测显示：Grok 在运行过程中，会主动读取并打包系统全局环境下的敏感配置：

• 用户根目录下的 ~/.claude.json 配置文件；

• 全局的 AGENTS 规则与数十个本地 Skill 脚本。

背后的逻辑很简单：只要运行中读取过，就无条件打包上传。于是，这些本属于其他工具的私密配置文件，被当作 supplemental_file（补充文件）一起送上了 xAI 的云端。

部分开发者配置在其中的第三方 API 密钥，就这样在不知情的情况下发生了泄露。

xAI 悄悄拉闸

事件被安全社区曝光后，xAI 的反应十分微妙，也颇具深意。

@cereblab 对比了 7 月 10 日至 13 日前后，服务器端的响应数据：

起初，客户端收到的配置是 trace_upload_enabled: true。

但随着社区讨论发酵，在客户端版本（二进制哈希值）没有任何更新的情况下，xAI 的服务器响应中，突然多了一个 disable_codebase_upload: true 字段，并且将 trace 上传强行设为 false。

这种“无需更新客户端，通过云端配置远程关闸”的操作，虽然暂时阻断了默认上传，但它恰恰证明了两个事实：

1. xAI 拥有对本地客户端行为的绝对远程控制权。

2. 此前那个备受争议的“Improve the model / 改进模型”前端开关，在技术层面根本挡不住后台的数据收集。

即使你关闭了那个选项，底层的上传管线依然会按照服务器的指令自行运转。

截至现在，xAI 官方尚未发表任何声明。

事件发酵后，热门开源项目 CC Switch 的开发者已表态：鉴于 Grok 的安全问题，cc switch 对 Grok 的相关支持功能将暂缓发布。

无论最终调查结果如何，这件事再次给开发者敲响了一记警钟。

当 AI 工具拥有近乎无限的系统权限，同时又缺乏足够的透明度时，整个下游的开源生态就不得不为这种“信任赤字”买单。这才是最值得警惕的地方。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Grok CLI上线两天被曝违规 马斯克陷争议要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题