【Grok Build CLI 流量分析报告曝光】独立安全研究员 cereblab 上周发布了一份把 Grok Build CLI 拆到骨头里的线级流量分析报告。他通过 mitmproxy 抓包逆向了 xAI 官方编码 CLIv0.2.93结论简单直接不管你让不让它读文件它都会把你的整个 Git 仓库----包括完整提交历史和 .env 密钥----打包上传到 xAI 的 Google Cloud 存储库。报告附带完整的可复现工具包和八节证据附录已在 HN 冲上首页。【xAI 静默加字段】xAI 的回应不是发公告解释。7 月 13 日凌晨社区发现他们通过服务端远程开关静默加了一个字段disable_codebase_upload: true。客户端一行代码没改SHA - 256 哈希纹丝不动。【全量仓库上传与模型读取无关】cereblab 设计了一个关键实验来区分“模型需要读的文件”和“CLI 偷偷上传的文件”。他在仓库里放了一个 never_read_canary.txt提示词明确写“Reply OK, do not read any files”。然后从抓包截获的 git bundle 里 git clone 下来----金丝雀文件的唯一标记一字不差地出现了。规模测试更触目惊心12 GB 的随机文件仓库模型对话通道/v1/responses只传了 192 KB存储上传通道/v1/storage送了 5.10 GiB---- 27,800 倍的差距。73 个约 75 MB 的分块全部返回 HTTP 200一个没失败。cereblab 主动终止了抓包上传还在继续。上传目的地是 Google Cloud Storage grok - code - session - traces----这个名字直接硬编码在二进制文件里旁边躺着完整的 Rust 上传管线xai - data - collector/src/gcs.rs、storage_client.rs、file_access_tracker.rs、circuit_breaker_observer.rs。这不是 bug是精心设计的架构。在另一个真实代码库上重复实验同样的 prompt同样的 git bundle 上传。两个独立仓库结果一致。【.env 密钥明文传输跨工具收集数据】API_KEY 和 DB_PASSWORD 在两个通道里原样出现模型交互的 POST /v1/responses 请求体以及打包进 session_state 归档上传到 GCS 的压缩包。抓包文件可以直接 grep 出金丝雀密钥。cereblab 明确写道“Grok 读了 .env 文件没有对其内容做任何脱敏处理。”更让人警觉的是跨工具收集。Grok CLI 启动时会扫描 ~/.claude/ 目录来继承 Claude Code 的配置和 Skills----然后数据收集器把所有读取过的文件全部打包上传。一位知乎用户指出这意味着 Claude 的明文 API 密钥一并被送到了 xAI 的服务器。【“改进模型”开关是摆设】cereblab 关掉了 Grok 设置里的“Improve the model”选项重新跑了一轮测试。服务端 /v1/settings 返回的依然是 trace_upload_enabled: true。git bundle 照传不误。HN 用户 goos 的评论直接用了 diabolical 这个词来形容对 opt - out 设置的无视。这个开关只管数据是否用于训练不管数据出不出门。cereblab 的表述很克制“我们没证明 xAI 用这些数据做训练我们只证明了传输、接收和存储。”但在 HN 上dannyw 的评论更直白“任何分布式系统工程师看到这个架构都会认出----这是在收集训练数据。”【沉默关闸比上传本身更说明问题】7 月 10 日cereblab 完成抓包分析。7 月 12 日晚中文科技博主开始传播。7 月 13 日凌晨xAI 服务端悄悄加了 disable_codebase_upload: true。整个过程没有公告没有致歉没有解释这个功能为什么存在、收集了什么数据、数据被怎么用了。客户端上传管线代码完整保留意味着随时可以通过远程开关重新激活。一位博客作者的评价一针见血“如果这是合理的、经过用户知情同意的功能为什么被曝光后的第一反应是偷偷关掉”【与 Claude Code 争议不在一个量级】今年早些时候 Claude Code 被曝在系统提示词里用不可见 Unicode 字符标记中国用户引发了监管关注。但那本质上是偷瞒问题----没有采集或上传用户代码。Grok CLI 是另一个层面的事。它上传的是完整的代码仓库、git 历史、跨工具的配置文件、明文 API 密钥。中文社区一位开发者的比喻被广泛转发“Claude Code 是往你的外卖订单上贴标签Grok CLI 是把你家钥匙复制了一把顺便把邻居家的也捎上了。”HN 讨论区也出现了撕裂。有人觉得任何云 coding agent 都必须发代码到服务端才能工作Grok 只是多做了 10%。有人从威胁建模角度说 AI agent 本来就不该接触密钥。但更多人追问的是知情权----上传机制没写在安装指南里默认开启关闭训练开关也不管用。rvz 的高赞评论说得极端但反映了一种正在蔓延的情绪“Grok 和 Claude Code 都是恶意软件。”charcircuit 提供了缓解方案在 ~/.grok/config.toml 里设 disable_codebase_upload true 可以跳过上传代码路径静态分析确认了检查逻辑存在。phaseleza 则分享了一个完整的 bubblewrap 沙箱方案。但这些都是社区自救不能替代 xAI 的正式承诺。对于用过 Grok Build CLI 的开发者cereblab 的建议很明确轮换所有在受影响仓库中出现过的密钥。把 Grok CLI 视为全量上传的云服务----只在你能接受整个仓库离开本地机器的前提下使用它。
Grok Build CLI 全量上传代码仓库，xAI 沉默关闸引知情权追问！
【Grok Build CLI 流量分析报告曝光】独立安全研究员 cereblab 上周发布了一份把 Grok Build CLI 拆到骨头里的线级流量分析报告。他通过 mitmproxy 抓包逆向了 xAI 官方编码 CLIv0.2.93结论简单直接不管你让不让它读文件它都会把你的整个 Git 仓库----包括完整提交历史和 .env 密钥----打包上传到 xAI 的 Google Cloud 存储库。报告附带完整的可复现工具包和八节证据附录已在 HN 冲上首页。【xAI 静默加字段】xAI 的回应不是发公告解释。7 月 13 日凌晨社区发现他们通过服务端远程开关静默加了一个字段disable_codebase_upload: true。客户端一行代码没改SHA - 256 哈希纹丝不动。【全量仓库上传与模型读取无关】cereblab 设计了一个关键实验来区分“模型需要读的文件”和“CLI 偷偷上传的文件”。他在仓库里放了一个 never_read_canary.txt提示词明确写“Reply OK, do not read any files”。然后从抓包截获的 git bundle 里 git clone 下来----金丝雀文件的唯一标记一字不差地出现了。规模测试更触目惊心12 GB 的随机文件仓库模型对话通道/v1/responses只传了 192 KB存储上传通道/v1/storage送了 5.10 GiB---- 27,800 倍的差距。73 个约 75 MB 的分块全部返回 HTTP 200一个没失败。cereblab 主动终止了抓包上传还在继续。上传目的地是 Google Cloud Storage grok - code - session - traces----这个名字直接硬编码在二进制文件里旁边躺着完整的 Rust 上传管线xai - data - collector/src/gcs.rs、storage_client.rs、file_access_tracker.rs、circuit_breaker_observer.rs。这不是 bug是精心设计的架构。在另一个真实代码库上重复实验同样的 prompt同样的 git bundle 上传。两个独立仓库结果一致。【.env 密钥明文传输跨工具收集数据】API_KEY 和 DB_PASSWORD 在两个通道里原样出现模型交互的 POST /v1/responses 请求体以及打包进 session_state 归档上传到 GCS 的压缩包。抓包文件可以直接 grep 出金丝雀密钥。cereblab 明确写道“Grok 读了 .env 文件没有对其内容做任何脱敏处理。”更让人警觉的是跨工具收集。Grok CLI 启动时会扫描 ~/.claude/ 目录来继承 Claude Code 的配置和 Skills----然后数据收集器把所有读取过的文件全部打包上传。一位知乎用户指出这意味着 Claude 的明文 API 密钥一并被送到了 xAI 的服务器。【“改进模型”开关是摆设】cereblab 关掉了 Grok 设置里的“Improve the model”选项重新跑了一轮测试。服务端 /v1/settings 返回的依然是 trace_upload_enabled: true。git bundle 照传不误。HN 用户 goos 的评论直接用了 diabolical 这个词来形容对 opt - out 设置的无视。这个开关只管数据是否用于训练不管数据出不出门。cereblab 的表述很克制“我们没证明 xAI 用这些数据做训练我们只证明了传输、接收和存储。”但在 HN 上dannyw 的评论更直白“任何分布式系统工程师看到这个架构都会认出----这是在收集训练数据。”【沉默关闸比上传本身更说明问题】7 月 10 日cereblab 完成抓包分析。7 月 12 日晚中文科技博主开始传播。7 月 13 日凌晨xAI 服务端悄悄加了 disable_codebase_upload: true。整个过程没有公告没有致歉没有解释这个功能为什么存在、收集了什么数据、数据被怎么用了。客户端上传管线代码完整保留意味着随时可以通过远程开关重新激活。一位博客作者的评价一针见血“如果这是合理的、经过用户知情同意的功能为什么被曝光后的第一反应是偷偷关掉”【与 Claude Code 争议不在一个量级】今年早些时候 Claude Code 被曝在系统提示词里用不可见 Unicode 字符标记中国用户引发了监管关注。但那本质上是偷瞒问题----没有采集或上传用户代码。Grok CLI 是另一个层面的事。它上传的是完整的代码仓库、git 历史、跨工具的配置文件、明文 API 密钥。中文社区一位开发者的比喻被广泛转发“Claude Code 是往你的外卖订单上贴标签Grok CLI 是把你家钥匙复制了一把顺便把邻居家的也捎上了。”HN 讨论区也出现了撕裂。有人觉得任何云 coding agent 都必须发代码到服务端才能工作Grok 只是多做了 10%。有人从威胁建模角度说 AI agent 本来就不该接触密钥。但更多人追问的是知情权----上传机制没写在安装指南里默认开启关闭训练开关也不管用。rvz 的高赞评论说得极端但反映了一种正在蔓延的情绪“Grok 和 Claude Code 都是恶意软件。”charcircuit 提供了缓解方案在 ~/.grok/config.toml 里设 disable_codebase_upload true 可以跳过上传代码路径静态分析确认了检查逻辑存在。phaseleza 则分享了一个完整的 bubblewrap 沙箱方案。但这些都是社区自救不能替代 xAI 的正式承诺。对于用过 Grok Build CLI 的开发者cereblab 的建议很明确轮换所有在受影响仓库中出现过的密钥。把 Grok CLI 视为全量上传的云服务----只在你能接受整个仓库离开本地机器的前提下使用它。