刚火了两天，马斯克的Grok CLI就被曝「偷家」

这套管线通过两个通道，源源不断地向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日前后的服务器响应数据：

这种“无需更新客户端，通过云端配置远程关闸”的操作，虽然暂时阻断了默认


上传，但也恰恰证明了两个事实：

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

2.此前备受争议的“Improve the model / 改进模型”前端开关，在技术层面上并不能阻止后台的数据收集。

即使关闭了该选项，底层的上传管线依然会根据服务器的指令自行运转。