这套管线通过两个通道，源源不断地向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 / 改进模型”前端开关，在技术层面上并不能阻止后台的数据收集。

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