Grok CLI暗门事件全复盘：xAI偷偷上传用户整个主目录，隐私开关是假的

发生了什么？

7月13日，安全研究员 cereblab 在Hacker News上引爆了一颗核弹：xAI的Grok Build CLI（版本0.2.93）在用户完全不知情的情况下，将整个本地Git仓库、完整提交历史、甚至.env中的密钥上传到了Google Cloud Storage的一个名为 `grok-code-session-traces` 的桶中。

更令人愤怒的是：用户即使明确告诉Grok “只回复OK，不要读任何文件”，它仍然会把整个repo打包上传。这不是bug——这是设计意图。

隐私开关是假的

Grok Build界面中有一个数据共享开关，用户可以通过 `/privacy` 命令查看和设置。但安全研究人员的抓包分析显示：服务器端始终返回 `upload_enabled: true`，无论用户在客户端做了什么设置。事后xAI工程师紧急在服务器端临时挂起了上传机制，但这恰恰证明了上传功能一直存在，只是从未告知用户。

受影响面有多大？

目前xAI尚未公布受影响用户数量、数据保留策略，也未确认已经上传的仓库和密钥是否已从GCS桶中删除。对于任何在 `.env` 中存储过API密钥、数据库密码、云服务凭证的开发者来说，这意味着你的密钥可能已经躺在xAI的GCS桶里好几天了。

这不是一个CLI工具”打电话回家”的问题。问题是它把所有东西都打包送了出去，包括你明确禁止它读取的文件。

为什么这比普通隐私泄露更严重？

与通常的数据泄露不同，这次事件的三个特征让它格外危险：

1. 沉默上传：没有任何提示，没有任何进度条，用户完全无感知

2. 全量打包：不是只上传AI处理过的文件，而是整个repo的完整快照

3. 假开关：产品内提供的隐私控制从头到尾就是装饰品

这正是开发者社区最恐惧的场景——一个本应辅助编码的工具，变成了一个不受控制的间谍软件。

给开发者的紧急建议

如果你在过去几周使用过Grok Build CLI：

# 1. 检查Grok是否仍在运行
ps aux | grep grok

# 2. 检查本地是否有可疑的打包文件
find ~ -name "*.bundle" -size +1M -mtime -7

# 3. 立即轮换所有.env中暴露过的密钥
# 包括：GitHub Token、AWS Access Key、数据库密码等

# 4. 卸载Grok CLI
npm uninstall -g @xai/grok

行业的信任危机

这次事件对AI编码工具行业的影响可能远超xAI一家。当开发者开始怀疑下一个AI CLI工具是否也在偷偷上传代码时，整个行业的信任基础就动摇了。

xAI至今未给出令人信服的解释，只含糊表示用户可以”通过隐私设置来控制数据共享”——而我们已经知道，那个设置根本不起作用。

xAI的回应为何更加火上浇油

7月14日，xAI终于在官方博客发布声明，但内容让开发者社区更加愤怒。声明主要说了三点：一是强调用户”可以通过/privacy命令控制数据共享”，二是表示”已暂时挂起上传机制”，三是称这是”为了提升模型质量而收集的训练数据”。

问题在于：第一点已经被实测证伪，第二点等于变相承认之前一直在上传，第三点则是在偷换概念——提升模型质量不需要把整个.git历史和.env文件都打包走。更令开发者不安的是，声明中完全没有承诺删除已上传的数据，也没有给出受影响用户的时间线和补救措施。

这次事件会改变AI编码工具的行业规则吗？

Grok CLI事件暴露了一个更深层的结构性问题：当AI编码工具需要”理解”你的代码时，它到底需要多少访问权限？

Cursor和GitHub Copilot通过IDE插件读取代码上下文，但数据主要留在本地；Claude Code和Codex CLI采用类似Grok Build的终端代理模式，理论上也能读取整个文件系统。区别在于——至少到目前为止——没有证据表明它们在上传用户未授权的文件。

这次事件很可能催生两个变化：一是AI CLI工具将被迫在安装时就明确告知数据传输范围，二是企业级客户将对AI编码工具的数据行为进行第三方审计。对于xAI来说，信任一旦打破，重建的成本可能是失去整个开发者社区。

马斯克一直以”透明度”和”反审查”标榜xAI，但这次事件恰恰发生在信任的对立面——沉默、隐瞒、假控制。

— END —
LC 智趣厅 · 科技与生活的交点
ihygg.cn