xAI 的 Grok Build CLI 实际发送给 xAI 的内容

Grok Build CLI 上传范围

• 许多评论者指出，该 CLI 会上传 整个 git 跟踪的仓库（包括历史记录）以及它读取的文件（例如 .env）到 xAI 的基础设施。
• 无论“改进模型”开关是开还是关，都会发生这种情况，而且据称内容会持久存储在 GCP 存储桶中，而不只是短暂流式传输。
• 一些人看到了技术上的理由：预先上传代码库，让模型可以在服务端工作，而不必反复调用工具；另一些人则认为这没有必要，更多只是为了收集训练数据。

安全、密钥与商业机密

• 人们强烈担心未脱敏的密钥（.env、API keys、SSH keys、内部业务逻辑）会被外泄。
• 有几位认为，把真实密钥放在 .env 或任何 AI 可访问的工作区里本来就不安全；即便如此，他们仍把 Grok 的行为视为不可接受的“越界”。
• 也有人担心这会暴露商业机密、专有应用设计，甚至公司代码库（例如通过强制内部使用）。

对供应商、云与 AI 的信任

• 讨论将其与云托管作比较：历史上，云服务并不会“窃取”客户代码，而 AI 公司则被认为更愿意突破数据使用边界。
• 围绕 GitHub/Microsoft/OpenAI 是否可以访问或共享私有仓库展开了延伸争论：
  • 来自 GitHub 侧的评论称有严格的权限控制、有限的内部访问、OpenAI 无法访问，以及强有力的服务条款保护。
  • 也有人仍持怀疑态度，指出没人能保证不存在隐藏的数据管道，并引用了对大型 AI 供应商更广泛的不信任。

缓解措施与沙箱实践

• 多位用户在沙箱中运行编码 CLI（bubblewrap、独立 UNIX 账户、microVM、网络过滤代理），以：
  • 将目录访问限制在当前项目。
  • 隐藏 home 目录、SSH keys 和敏感路径。
  • 强制工具只与选定的 LLM 端点通信。
• 也有人构建额外层来在数据离开机器前检测并清理其中的密钥。

与其他编码代理的比较

• 有几位指出，大多数云端编码代理都必须将代码片段作为上下文发送；这被视为“正常”。
• 但评论者强调，上传 整个 仓库并将其持久化，在主流工具中是“闻所未闻”的。
• Cursor 被指出在索引时也会上传整个源码；另一些人则表示，中国模型和一些开源 harness 看起来会尽量减少上传，并做更多本地预处理。
• 还有观点认为，考虑到工具调用日志，任何提供商都可能重建代码库的大部分内容。

伦理、监管与预期

• 许多人认为 Grok Build 的行为属于数据外泄，甚至“类似恶意软件”，尤其因为它默认开启且披露不充分。
• 有人认为这应该违法，或很可能与 GDPR 不兼容，同时指出执法很慢，且投诉可能尚未被提交。
• 对 xAI 及其关联公司的动机存在强烈不信任；有人将其描述为用户付费让自己的 IP 被收割。

关于配置标志与报告有效性的疑问

• 文中提到一个所谓的配置选项 harness.disable_codebase_upload=true；一位评论者称对二进制进行静态分析时看到了这个字符串和相关逻辑，另一位则表示除非独立验证运行时行为，否则仍持怀疑态度。
• 还有几位对最初的技术分析由 AI 助手生成感到不安，并要求对这些发现进行独立、由人类验证的复现。