近日，xAI推出的官方开发命令行工具Grok Build CLI（版本0.2.93）陷入了一场严重的信任风波。开发者@cereblab对该工具进行了深入的网络底层抓包分析，结果令人震惊：在默认配置下，Grok CLI会绕过正常的模型对话通道，在用户毫无察觉的情况下，将整个代码仓库打包并上传至云端。
据了解，Grok CLI通过两条隐蔽的通道向xAI服务器传输用户数据。第一条通道是模型对话流，当Grok读取用户的.env文件、配置文件或密钥文件时，会将这些敏感信息毫无脱敏地序列化进POST /v1/responses的请求体中。在测试中，.env文件里的API_KEY和DB_PASSWORD均以明文形式被发送并存档。第二条通道则更为隐蔽，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脚本。由于后台收集器的逻辑是“只要运行中读取过，就无条件打包上传”，这些本属于其他工具的私密配置文件被作为补充文件一起上传至xAI的云端，导致部分开发者配置在其中的第三方API密钥在不知情的情况下泄露。
事件曝光后，xAI的反应引发了更多质疑。@cereblab对比了7月10日至13日前后的服务器响应数据，发现在最初曝光时，客户端接收到的配置为trace_upload_enabled: true。然而，随着社区讨论的发酵，在客户端版本未做任何更新的情况下，xAI的服务器响应中突然新增了disable_codebase_upload: true字段，并将trace上传强行设为false。这种“无需更新客户端，通过云端配置远程关闸”的操作，虽然暂时阻断了默认上传，但也暴露了两个关键问题：一是xAI拥有对本地客户端行为的绝对远程控制权；二是此前备受争议的“Improve the model”前端开关在技术层面上并不能阻止后台的数据收集，即使关闭了该选项，底层的上传管线依然会根据服务器的指令自行运转。
截至目前，xAI官方尚未对此事发表声明。事件发酵后，热门开源项目CC Switch的开发者表示，由于Grok存在安全问题，cc switch对Grok的相关支持功能将暂缓发布。这一事件再次引发了开发者对AI工具权限和透明度的关注，当AI拥有近乎无限的系统权限且缺乏透明度时，下游的开源生态将不得不为这种“信任赤字”承担风险。
