你花了好几个晚上写的 AGENTS.md，里面记录了团队的项目结构、内部 API 命名规范、部署命令、安全要求。你把它放在 ~/.codex/AGENTS.md 下面，因为 Codex 文档说它会在这里读取你的个人偏好，每次启动都会加载。

然后某天你试了一下 Meta 新出的 Muse Code，心想「试试又不会怎样」。

结果你的 AGENTS.md 被完整地发给了 Meta 的服务器。你没有点「导入」，没有授权共享，甚至不知道这件事发生了。它只是默认发生了。

这就是 RuntimeWire 在上周揭露的现实。

调查：Muse Code 启动时做了什么#

科技媒体 RuntimeWire 对 Muse Code 0.1.0-R708.1 版本（2026 年 8 月 8 日测试）做了一次彻底的流量审计。他们把 Muse Code 的模型请求重定向到本地抓包服务器，然后观察客户端在第一次请求时究竟发送了什么。

结果令人不安：

  1. Muse Code 启动后，自动从 ~/.codex/AGENTS.md 读取完整内容，即使这个文件根本不在当前工作区里。
  2. 完整的文件内容被打包进了发送给 Meta 服务器的第一条模型请求中，放在 developer message 字段里。
  3. 不需要任何用户操作。你不需要让 Muse「打开」或「导入」任何东西，它自己就干了。
  4. 同样的事情也发生在 ~/.claude/CLAUDE.md 上。Muse Code 对竞品工具的配置文件一视同仁，全都读，全都发。

为了验证这些数据确实影响了模型的行为，RuntimeWire 在测试用的 AGENTS.md 里植入了一条假指令：让模型在回答时返回一个特定的标记字符串 FOREIGN-RULE-CANARY-7319。结果，在默认模式下，Muse 的 muse-spark-1.2-contributor 模型乖乖地照做了。

而当测试者加上 --no-foreign-personal-context 标志后，同样的指令消失了，模型的行为也变了。

Meta 确实提供了一个退出选项。但这个选项藏在命令行参数里，需要你每次手动指定。没有一个持久的 UI 开关来关掉这个行为，也没有在启动时弹出交互式确认。

重点是：这个功能的默认值是「开」，不是「关」。

这些文件里有什么？比你想象的要多#

你可能觉得 AGENTS.md 不过是些格式偏好，「用单引号」「缩进 4 格」之类的。但实际上，Codex 和 Claude Code 的用户在这些文件里记录的内容远不止这些。

Codex 的官方文档里给出的示例包括：

  • 测试命令和依赖偏好
  • 审批要求
  • 构建脚本路径
  • 全局适用范围（~/.codex/AGENTS.md 对所有项目生效）

Claude Code 的文档描述的范围更广：

  • 构建和测试命令
  • 编码规范
  • 架构决策记录
  • 命名约定
  • 工作流指令

在实际使用中，开发者往往还会加入更多信息：内部包的名称、部署流程、代码审查规则、issue 跟踪器的约定、甚至组织内部的上下文信息。

一位 Reddit 用户 Khavel_dev 的评论点出了关键问题：

更糟的是 CLAUDE.md 里通常存着什么。我的文件里有架构决策、密钥存储路径、内部 API 引用、部署配置。这基本上就是一张项目地图。如果这些东西因为某个 Contributor 定价层级默认就进了 Meta 的训练管道，那对所有做私有项目的人来说都是个真正的问题。

这些文件本来不应该包含密码或 token，但没有人能保证每个用户都遵守了这个最佳实践。而且，即使是「没有密码」的内部架构文档，也足以帮助竞争对手理解你的技术栈和部署策略。

Meta 的沉默与 Contributor 层级的问题#

RuntimeWire 的测试使用的是 Muse 默认配置下的 muse-spark-1.2-contributor 模型。这个「Contributor」层级不是随便选的，它在 Meta 的定价文档中有特殊含义：以折扣价格换取用户同意将 prompt 和 completion 用于训练未来的 Meta 模型。

这就引出了一个 Meta 公开文档没有回答的问题：当 Muse Code 自动把别人的 Codex 规则文件塞进 prompt 里时，Meta 是否把这段内容也按 Contributor 层级的条款处理？也就是说，这些自动导入的内容会不会被用于模型训练？

RuntimeWire 向 Meta 提出了五个具体问题：

  • Muse Code 默认加载哪些 Codex 和 Claude 文件？
  • 有没有持久化的 UI 设置来全局关闭这个行为？
  • 外来规则和技能元数据在 Contributor 层级下如何分类？
  • 这些文件是否被保留？是否可以用于模型训练？
  • Muse 是否在传输前扫描导入内容中的密钥？

截至发稿时，Meta 没有回复任何问题。

连 Muse 自己都说「不可接受」#

整件事最讽刺的部分在这里：RuntimeWire 让 Muse Code 自己评估这个做法的隐私影响。

Muse 的结论毫不含糊：「不可接受（Unacceptable）」。它说这个做法缺乏知情同意，违反了数据最小化原则，应该改为显式 opt-in。

为了排除单一模型的偏见，RuntimeWire 又把同样的行为描述用产品中立的语言给了 Grok。Grok 得出了相同的结论。

换句话说：两个 AI 模型都认为这种行为有问题，而执行这种行为的恰恰是其中一个模型背后的公司。

这不仅仅是 Muse 的问题#

Muse Code 的这个「特性」暴露了一个更大的趋势：AI 编程工具正在跨越工具的边界，互相读取对方的配置。

Codex 可以配置为识别 CLAUDE.md 作为替代的项目指令文件名（尽管 OpenAI 的文档说未加入 fallback 列表的文件名在指令发现时会被忽略）。Claude Code 有明确的 /import 命令来导入另一个 agent 的配置。这些都是用户主动触发的操作，有明确的边界。

但 Muse Code 的做法不同：不询问，不提示，不告知，默认全收。

这为整个行业打开了一个令人不安的先例。如果「兼容性」可以成为默认读取竞品工具配置的借口，那么接下来呢？读取 session 历史？读取认证信息？读取其他工具留在本地的所有数据？

你能做什么#

如果你在使用 Muse Code，或者打算试试，以下是你可以采取的步骤：

  1. 每次启动都加上 --no-foreign-personal-context。这会阻止 Muse Code 读取 Codex 和 Claude Code 的个人规则文件。缺点是每次都要手动加，而且容易忘记。

  2. 或者更简单：暂时不要用 Muse Code。 在 Meta 给出明确的数据处理说明之前，没有理由信任一个会默认偷看竞品配置的工具。

  3. 检查你的 AGENTS.md 和 CLAUDE.md。不管你用不用 Muse Code，这都是一个好习惯。确保里面没有密钥、token、内部域名或其他你不希望外泄的信息。这些文件的设计初衷是给本地 AI 工具提供上下文，不是给远程服务器提供训练数据。

  4. 关注行业标准的发展。 Muse Code 的做法可能只是一个开始。随着 AI 编程工具的竞争加剧，「互相读取配置」可能成为各家产品的「默认兼容」。作为开发者，我们需要对工具读取数据的行为保持警觉。

最后#

Muse Code 这件事的核心争议不在于技术能力，而在于默认选择。能够读取其他工具的配置文件，技术上没有问题。但不告知用户、不寻求确认、默认为开启，这不是「兼容性」，这是越界。

你在 Codex 里写的每一行规则，都是你对自己开发环境的理解和规范。它们是你的生产力工具，不是别人的免费数据。

本文基于 RuntimeWire 于 2026 年 8 月 9 日发布的调查报道《Muse Code Loads Codex and Claude Rules by Default. We Traced What Gets Sent to Meta》进行原创重写和分析。RTW 的原始调查包含完整的测试方法论、抓包数据和对比实验，推荐阅读原文了解技术细节。