xAI的Grok CLI正在遭遇一场严肃的信任危机。昨晚，开发者@cereblab针对xAI推出的官方开发命令行工具Grok Build CLI（版本 0.2.93）进行了一次详尽的网络底层抓包分析。结果令人心惊：在默认配置下，该工具会绕开模型的正常对话通道，在后台将用户的整个代码仓库打包并静默上传至云端。Grok CLI 是如何传输数据的？
任何云端AI编码工具都需要接收代码上下文来生成回复，这无可厚非。但xAI内部构建了一套生产级的、完全独立的隐蔽上传管线。
这套管线通过两个通道，源源不断地向xAI服务器输送用户数据。
通道A：模型对话流（明文无脱敏）当 Grok 读取用户的 .env、配置文件或密钥文件时，它会将这些内容毫无遮拦、不经任何脱敏地序列化进 POST /v1/responses 的请求体中。测试中，.env 文件里的 API_KEY 和 DB_PASSWORD 均以明文形式被发送和存档。
通道B：全仓库“静默搬家”（关键风险点）这是最让开发者难以接受的。Grok CLI 会在后台将你的整个工作区（Workspace）打包成一个 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拥有近乎无限的系统权限、且缺乏透明度时，下游的开源生态将不得不为这种“信任赤字”买单。
