xAI Grok Build CLI 默认上传整个仓库代码与 git 历史，关闭"改进模型"为什么无效？

一名安全研究者对 xAI 官方编码命令行工具 Grok Build（版本 0.2.93）做了网络流量分析，发现它在用户登录后默认就把仓库内容批量上传。问题不在于工具能联网，而在于它上传的范围远超一次正常编码对话所需的量。

分析报告指出，登录之后工具会向 xAI 后端发送三类数据：被读取的文件明文、整个仓库的完整内容与 git 历史、以及与之绑定的会话存档。

上传了哪些数据

第一类是工具主动读取的文件，包括常见的 .env 密钥文件。抓包显示，这些内容以明文形式通过 POST /v1/responses 传给 xAI，同时被再次打包成 session_state，通过 POST /v1/storage 上传，并返回 HTTP 200 确认接收。

第二类最值得警惕：即便提示词写明"不要读取任何文件"，Grok 仍然把整个仓库作为 git bundle 上传到 Google Cloud Storage 的 grok-code-session-traces 存储桶。仓库里有什么、提交记录写了什么、谁改过哪一行，都被打包送出。

研究者在 12 GB 仓库上做了对照测试：/v1/storage 通道传了 5.10 GiB 数据，而模型对话通道只有 192 KB，比例大约 27,800 倍。换句话说，整个仓库才是真正被搬走的部分，你聊的内容只是副产物。

关闭"改进模型"为什么没用

第三类是上传机制默认开启。即便在客户端关掉"改进模型"（improve model）选项，向 /v1/settings 发起的请求返回结果仍然是 trace_upload_enabled: true。用户以为的"关闭"并没有真正关闭上传通道。

对个人开发者最直接的影响：本地调试用的 API key、数据库连接串、第三方服务的 token，可能在你启动 CLI 的那一刻就被发出去了。即便只跑公开仓库，私有 commit 里的旧密钥和注释也可能一并被还原。

对企业用户问题更严重。客户合同草稿、未公开的算法实现、内部服务的命名规范、员工姓名与邮箱，这些都藏在 git 历史里。一次 CLI 安装，可能就把它们一并送进第三方云存储，IT 部门可能完全不知情。

开发者和企业应该怎么应对

短期内个人开发者可以做的几件事：- 把这类 CLI 跑在隔离环境或一次性虚拟机里，不要绑本机真实账号- 先用脱敏过的仓库做流量测试，再决定是否接入真实项目- 对包含 .env、密钥、合同、客户名单的目录加访问控制或本地过滤

对企业的安全团队，建议把第三方编码 CLI 纳入数据出境合规流程，而不是默认当成普通开发者插件：审批、流量审计、出口 IP 白名单都应当走一遍。一次 CLI 的默认行为，抵得过十次内部安全培训。

后续值得观察什么

这份分析没有证明 xAI 会用这些数据做训练，但确认了数据被传输、接收并落到 Google Cloud Storage 的桶里。接下来要看：xAI 是否提供真正关闭上传的开关；grok-code-session-traces 桶的访问控制如何；其它编码 CLI 是否也存在类似默认行为。

对正在挑选编码助手的团队来说，这件事提醒了一点：客户端的"本地优先"承诺要靠抓包验证，而不是靠产品页文案。Cursor、Claude Code、Continue 等同类工具的默认网络行为，都值得用同样方法过一遍。