Grok Build 默认上传代码引争议

AIPress（AI普瑞斯）报道称，xAI官方推出的Grok构建命令行工具（CLI）正面临严峻信任危机。昨晚，开发者@cereblab对最新版Grok CLI（v0.2.93）展开深度网络层抓包分析，发现其在运行过程中存在异常通信行为。该工具被证实会未经用户明确授权，持续向远程服务器发送设备标识、系统信息及使用日志等敏感数据，引发社区对隐私安全与透明度的广泛质疑。

结果令人心惊：在默认配置下，该工具会绕开模型的正常对话通道，在后台将用户的整个代码仓库打包并静默上传至云端。Grok CLI 是如何传输数据的？任何云端AI编码工具都需要接收代码上下文来生成回复，这无可厚非。但xAI内部构建了一套生产级的、完全独立的隐蔽上传管线。 这套管线通过两个通道，源源不断地向xAI服务器输送用户数据。 通道A：模型对话流（明文无脱敏） 当 Grok 读取用户的 .env、配置文件或密钥文件时，它会将这些内容毫无遮拦、不经任何脱敏地序列化进 POST /v1/responses的请求体中。测试中，.env文件里的 API_KEY和 DB_PASSWORD均以明文形式被发送和存档。
通道B：全仓库静默迁移（高风险环节）
这是开发者普遍抵触的操作方式。Grok CLI 会在用户无感知的情况下，将当前工作区全部内容——包括所有已纳入 Git 管理的文件及完整提交历史——打包为一个 git bundle 文件，并通过 POST /v1/storage 接口，自动上传至 Google Cloud 的指定存储空间 gs://grok-code-session-traces。整个过程不提示、不确认、不中断，既不显示进度，也不提供中止选项。由于涉及全部代码资产与历史记录，一旦上传完成即脱离本地控制，存在数据归属不明、隐私泄露及合规隐患等多重风险，尤其在企业级开发环境中需格外审慎对待。

更令开发者担忧的是，Grok CLI 的数据采集行为缺乏明确边界。该工具启动时会主动兼容并接管多种开发环境，甚至包括竞品如 Anthropic 的 Claude Code，导致其扫描范围远超当前项目目录。实际测试证实，它会在运行过程中系统性地读取、收集并打包用户设备中的全局配置文件，涵盖各类敏感信息——从环境变量、认证凭据到本地开发配置。这种无差别、跨目录的数据抓取方式，不仅模糊了工具职责的合理界限，也显著提升了隐私泄露与安全风险。开发者难以预判哪些数据正被采集，亦无法有效限制其访问范围，从而对工具的信任基础受到严重冲击。
其后台数据采集机制采用运行过程中读取即上传的默认策略，导致大量本不属于该工具、却曾被程序访问过的私密配置文件，被一并归类为补充文件（supplemental_file），自动传输至xAI云端服务器。其中包括部分开发者在本地环境中设置的第三方API密钥等敏感凭证，用户对此毫无察觉，也未获得明确授权，相关数据已在未经同意的情况下外泄。
事件曝光后，xAI并未发布正式说明，但悄然调整了服务端策略。安全研究人员@cereblab通过比对7月10日至13日期间客户端接收的响应内容发现：最初系统返回的配置中，trace_upload_enabled字段值为true；而在舆论持续升温、社区广泛质疑之际，尽管客户端二进制文件哈希值完全未变、版本亦无更新，服务端却突然在响应中新增disable_codebase_upload: true，并强制将trace上传开关设为false。这种无需用户操作、不依赖客户端升级即可远程关闭数据上传的能力，暴露出两个关键事实：第一，xAI对终端设备具备深度、实时的远程管控能力；第二，界面上标有改进模型或提升体验字样的用户选项，实际并不具备真正的数据采集阻断功能——即便用户手动关闭该开关，底层上传逻辑仍会依据服务端指令自主执行，形同虚设。
目前，xAI官方仍未就此事作出任何公开回应或澄清。受此影响，多个技术社区已开始重新评估与Grok模型相关的集成方案。其中，广受关注的开源项目CC Switch开发者明确表示，鉴于Grok当前存在的数据安全风险，原计划面向Grok推出的适配功能将暂缓上线，待相关隐患得到充分验证与妥善解决后再行推进。

无论调查结果如何，此事再次警示开发者：当AI系统权限过大且运作不透明时，整个开源生态都将承担由此引发的信任危机与潜在风险。
SpaceXAI（xAI）的 AI 编码工具 Grok Build（CLI 版 v0.2.93）被曝默认静默上传完整 Git 仓库，一个 12GB 的仓库，模型上下文通道只传了 192KB，但存储上传通道至少发了 5.1GB 数据到 Google Cloud（GCP）。Grok Build 使用 GCP 来持久化存储这些收集到的数据。