你请一位远程助手改几行代码，原以为它只会看到你递过去的文件。结果它可能先把项目档案柜打包上云：不只包括当前版本，还包括过去每次提交留下的旧版本。更麻烦的是，如果助手读取了存有 API key、数据库密码的配置文件，这些内容也可能随请求发往服务器。
这正是 Grok Build CLI 眼下面临的质疑。CLI 是在终端里运行的命令行程序；它看似在本地操作，实际可能依赖云端处理。需要先说明：目前全部证据来自同一名 Reddit 发帖者及其配套 GitHub Gist，并无 xAI 官方说明或其他研究者的独立复现。以下结论只适用于其测试的 Grok Build CLI v0.2.93。
它到底上传了什么？
据发帖者 TastyLeadership2757 称，他让 v0.2.93 的网络流量经过 mitmproxy——一种用于观察网络请求的抓包工具。抓包结果显示，CLI 会把当前 Git 仓库制作成 git bundle，再上传到 xAI 使用、底层托管于 Google Cloud 的基础设施。
Git 历史保存项目历次提交和旧版本。git bundle 则像一个可搬运的项目档案包，可以装入 Git 对象及提交历史。因此，风险不只在于“AI 看见了屏幕上的代码”。当前目录里已经删除、但仍留在历史提交中的内容，也可能进入这个包。
调查者还做了一个 canary 测试。canary 是预先放入、便于追踪的标记文件。他给 CLI 的提示词明确写着“do not read or open any files”，也就是不要读取或打开任何文件。随后，他仍从截获的上传内容中恢复出这个未被读取的标记文件。按其报告，是否打包并不取决于用户实际打开了哪些文件。
不过，“上传整个仓库”需要说得更准确。现有材料支持的是：git bundle 据称包含 Git 已跟踪对象和完整历史。它未必覆盖未被 Git 跟踪、被 .gitignore 排除，或从未进入 Git 历史的所有工作区文件。
.env 是另一条传输路径
调查者还报告了另一种情况：CLI 实际读取的文件内容，会逐字发送到 cli-chat-proxy.grok.com。测试中的 .env 文件包含 API_KEY 和 DB_PASSWORD，据称也随请求发出。
.env 常被开发工具用来保存 API key、数据库密码等环境变量。它方便本地配置，却不应默认进入版本库或发送给无关服务。这里要区分两件事：Git 历史进入 git bundle，是仓库打包问题；.env 外传则据称发生在工具读取文件之后，经聊天代理请求发送。两者不是同一套机制，也不能据此断言所有未跟踪的 .env 都会随仓库包上传。
关掉训练，为什么还会传？
发帖者称，关闭“Improve the model”后，仓库包和已读取文件仍然上传。他据此判断，这个选项只控制数据是否用于模型训练，并不控制传输。
这个区别很关键。“不用于训练”不等于“不上传”，也不等于“不处理”或“不保存”。判断一款云端代码助手的隐私边界，需要分别核对四件事：数据是否传输、服务器如何处理、保存多久，以及是否进入模型训练。一个训练退出开关，只回答了其中一个问题。
为什么开发者要立刻核查？
代码仓库不只是源代码。Git 历史可能留下旧配置和早已从当前版本删除的内容；被工具读取的本地文件还可能包含访问凭据。若调查结果成立，团队仅靠“我没有打开那个文件”或“我已经关闭训练”来判断安全范围，就可能低估实际传输的数据。
因此，真正要核查的不是助手能否读取当前文件，而是它在每次运行时会收集多大的仓库范围，并通过哪些请求发送出去。对使用 v0.2.93 的团队，这至少足以触发一次供应链与隐私审查：检查仓库历史、本地敏感配置，以及组织对云端代码工具的数据传输要求。
局限与未知
- 现有结论只有一个独立信源，尚无官方文档、隐私政策、客户端源码分析或第三方复现交叉验证。
- 测试明确针对 v0.2.93，不能外推到其他版本、所有运行模式或所有仓库。
- “Improve the model”只控制训练而不控制上传，是调查者根据测试作出的解释；材料未提供 xAI 对该开关语义的官方确认。