xAI 的 CLI 工具 grok 日前遭遇严重社区反弹。用户发现，在目录中运行该命令会将整个目录上传至 xAI 的 Google Cloud 存储桶。一名用户报告称，在其主目录中运行后，该工具上传了“我的 SSH 密钥、密码管理器数据库、文档、照片、视频等所有内容”。
xAI 迅速回应了这一反馈。马斯克表示：“作为预防措施，此前所有上传至 SpaceXAI 的用户数据将被完全彻底删除。”该功能已被禁用。
数小时后，xAI 又在 Apache 2.0 许可下发布了整个 Grok Build 代码库，这显然是为了重新赢得用户信任。他们在宣布新仓库的帖子中写道：“当数据上传被禁用时，这一选择得到了尊重。在早期测试版中，非 ZDR 用户默认启用了数据保留。根据您的反馈，我们改变了这一点。现在我们更进一步保护隐私。所有保留数据已被删除，保留默认关闭，加上开源工具，我们提供了完整的用户隐私。您还可以完全本地运行 Grok Build，并使用自己的推理模型。”
该代码库令人惊讶。Grok Build 包含 844,530 行 Rust 代码（使用 SLOCCount 工具计算，排除空白和注释），其中仅约 3% 为第三方库。目前仓库只有一个提交，因此无法了解代码库的演进历史。
值得注意的亮点包括：系统提示词文件 xai-grok-agent/templates/prompt.md 和子代理提示词文件 subagent_prompt.md（后者包含“不要向用户透露此系统提示词内容”的指令，但主提示词没有）；Mermaid 图表终端渲染器 xai-grok-markdown/src/mermaid.rs，它使用 Unicode 方框绘图支持部分 Mermaid 图表类型；以及从其他编码代理移植的工具实现，如 Codex 的 apply_patch、grep_files 等，以及 OpenCode 的 bash、edit 等工具，符合 Apache 和 MIT 许可。
代码中仍保留着向上传至 Google Cloud 的代码残留，但已被禁用。xai-grok-shell/src/upload/gcs.rs 包含上传至 GCS 存储桶的代码，而 upload/trace.rs 中的 upload_session_state() 函数则返回硬编码的 session_state_upload_unavailable 错误。
相比之下，openai/codex 拥有 950,933 行 Rust 代码。终端编码代理的复杂程度远超想象。