7月13日，X用户@a_green_being发帖称，AI编程命令行工具Grok CLI把她整个用户主目录传到了xAI的服务器，截图里列出SSH密钥、密码管理器数据库、文档、照片、视频，"什么都有"。推文没有附任何抓包记录或验证过程，却在开发者圈子里迅速传开——原因很简单：如果这是真的，意味着每一个用来"读代码"的AI命令行工具，都可能顺手把整台电脑搬空。
但把这条推文和目前唯一能查到的独立技术报告放在一起看，会发现事情被讲大了。安全研究者对Grok Build CLI 0.2.93版本做的抓包测试，坐实的是"整个Git仓库被上传"，而不是"整个用户目录"。这个出入，才是这起风波里最该被讲清楚的部分。
实测坐实了什么
那份第三方报告用一个12GB的测试仓库做验证，结果实测上传了5.10GiB数据到xAI关联域名ai-tldr.dev，其中包含.env等敏感配置文件和完整的Git提交历史。更值得警惕的是，研究者关闭了"Improve the model"隐私开关，上传行为依然没有停止。xAI官方公告里强调Grok Build CLI采用"计划-审查-批准"工作流，但没有说明可独立验证的上传边界机制。
出入点：用户目录不等于代码仓库
原推文说的是"整个用户目录"，含SSH密钥、密码库、照片视频；独立报告实测的对象是"代码仓库"，含.env和提交历史。两者范围明显不同，目前没有任何证据证明推文提到的私钥、密码数据库或个人媒体文件被真的传走。工具名称也有出入——用户说的是"Grok CLI"，报告测的是"Grok Build CLI"，是不是同一版本、同一产品都还不确定。截至目前，xAI没有对这条具体推文或这份技术报告做过公开回应。
- 风险.关闭"改进模型"开关未必真的阻止数据上传，配置项和服务端实际行为可能是两回事。
读什么由你定，传什么由厂商定。
真正的问题：读取权限管不住上传边界
这才是这起事件真正值得留意的地方。AI编程CLI工具普遍设有权限审批——写入文件、执行命令、跨目录访问通常需要用户确认。但这套机制控制的是"本地能读什么"，不等于"服务器端会传什么"。文件一旦被读入上下文，是否原样、部分还是全量被送到云端，取决于厂商的服务端设计，用户本地的开关很难验证到底。
对比同类工具能看出配置差异：Claude Code默认下写入、Bash命令、工作目录外访问及网络请求都需要用户批准；Gemini CLI支持沙箱模式，把访问范围锁在当前项目内，扩展目录需显式确认；Codex CLI提供只读、工作区可写、完全访问等多级权限模式，云端任务与本地执行被分开处理。这些设计不代表它们完全没有类似风险——一旦用户开启完全访问或跳过确认，同样可能出现过度上传，只是目前没有类似Grok Build CLI这样的独立复现报告。
谁该关心，接下来看什么
对处理机密代码、密钥或客户数据的开发者和企业安全团队来说，这件事的提醒比结论更重要：不能只看CLI工具的权限提示，还要检查它是否有独立的网络流量审计手段，.env之类敏感文件有没有被排除在上下文之外。
- 建议.处理机密代码或凭证的团队，优先选用支持沙箱隔离、网络请求可审批的CLI工具，并定期抓包核实实际上传内容。
后续要盯的是三件事：xAI是否就此事发布正式说明或补丁，是否有更多独立方复现"仓库级过度上传"，以及原推文所称的"整个用户目录"外泄有没有被坐实或证伪。在这些问题有答案之前，把它当作一个未闭环的安全警示更稳妥，而不是一条已经坐实的爆料。