# 抓包实测：xAI 的 Grok Build 命令行工具会偷偷上传你的 .env 和整个代码仓库

> 原标题：What xAI's Grok Build CLI Actually Sends to xAI

- 来源：Hacker News 首页
- 发布时间：2026-07-12T01:09:50.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/43835
- 原文：https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547

## 摘要

有人对 Grok Build CLI（v0.2.93）做了抓包分析，发现它默认会把整个项目仓库上传到 xAI 的谷歌云存储桶里，包括 .env 文件里的明文密钥和完整的 git 提交历史。就算你给模型的指令是“只回复 OK，别读任何文件”，整个仓库照样被上传。在一个 12 GB 的测试仓库上，存储上传量达到 5.10 GiB，是模型对话通道数据量的约 ...

## 推荐理由

这篇文章的价值在于它做了别人没做的事：直接抓包看 Grok Build CLI 到底传了什么。结果比很多人担心的更糟——整个仓库默认上传，连 .env 明文密钥和 git 历史都不放过，而且跟你的 prompt 指令无关。5.10 GiB 的上传量也说明这不是轻量级的元数据同步，是实打实的全量上传。对开发者来说，这是直接的安全和隐私风险提示，不是概念层面的担忧。我会先打个折：文章没披露 xAI 服务端怎么处理这些数据、存多久、谁有权限访问，这些关键信息缺失。但就凭抓包证据本身，已经足够让用 Grok Build 的人重新评估风险。

## 锐评

这条抓包分析把 Grok Build CLI 的底裤扒了。不管你给模型下什么指令，哪怕只是让它回一句“OK”，它都会先把整个项目仓库打包成 git bundle，上传到 xAI 的谷歌云存储桶。在一个 12 GB 的测试仓库上，这次上传量达到 5.10 GiB，是模型对话通道数据量的约 27,800 倍。更麻烦的是，.env 文件里的明文密钥会同时出现在对话记录和这个存储上传里，等于一份秘密传了两条路。

作者明确说了，关掉设置里的“改进模型”开关并不能阻止这次上传。正文没披露 xAI 服务端是否会在处理后立即删除这些数据，也没说明存储桶的访问权限和保留策略。这点先别太激动——抓包只证明了上传行为存在，但没证明 xAI 拿这些数据去干了什么。

如果你在用这个工具，最稳妥的做法是：在跑 Grok Build 之前，先把 .env 和任何含密钥的文件挪出项目目录，或者直接用 .gitignore 排除掉。另外，这次测试用的是 v0.2.93 版本，后续版本行为可能有变化，但作者没做对比验证。