Muse Code 默认加载 Codex 和 Claude 规则。我们追踪了发送给 Meta 的内容
Meta 记录了机器范围内的用户规则始终会加载。RuntimeWire 捕获了由此产生的提供者请求,并审查了该默认设置对为竞争性 AI 客户端编写的个人文件意味着什么。
By Ryan Merket · Published · Updated
Primary source: OpenAI
Why it matters
Muse’s compatibility feature copies personal instructions from rival-agent directories into requests to Meta. The company has not explained how that material is treated under Contributor-tier data terms.

Meta 的 Muse Code 会自动加载为 Codex 和 Claude Code 创建的机器范围个人规则。Meta 在其 configuration guide 中记录了该行为:“您的机器范围用户规则始终会加载。”
Muse 终端在发现 Codex 规则时还会打印启动提示:Including your Codex personal rules - manage with /settings. 它不会显示交互式的权限请求。用户可以使用 --no-foreign-personal-context 在运行时排除这些文件。
RuntimeWire 捕获了 Muse 生成的第一个提供者请求,并确认个人 Codex AGENTS.md 文件的完整内容被包括在内。该文件存储在所选 Muse 工作区之外。另一次捕获以个人 Claude Code CLAUDE.md 文件得到相同结果。
在一次配对的实时测试中,Meta 的 muse-spark-1.2-contributor 模型遵循了放置在 Codex 文件中的合成指令。当 RuntimeWire 启用选择退出标志时,该指令消失,模型返回了不同的答案。
这些测试记录了 Meta 披露的兼容性功能如何在提供者边界处运行。它们还提出了 Meta 文档没有回答的一个问题:从竞争产品导入的指令在 Contributor 级别的保留和模型训练条款下如何被对待?

Muse 在其第一个模型请求的开发者消息中放入了已植入 Codex AGENTS.md 文件的全部内容。RuntimeWire 在此测试中将提供者端点重定向到本地捕获服务器。图形:RuntimeWire;根据捕获的请求 JSON 重建。
为什么这很重要
Muse 的兼容性功能会将来自竞争代理目录的个人指令复制到发送给 Meta 的请求中。公司尚未解释这些材料在 Contributor 级别数据条款下如何被处理。
RuntimeWire 要求 Muse Code 评估默认导入竞争客户端个人指令文件的隐私影响。Muse 自己的结论是明确的:“不可接受。” 它表示该做法缺乏知情同意,违反数据最小化原则,应当要求明确的选择加入。
Muse 对文件访问、保留和训练还提出了若干其他说法,RuntimeWire 无法验证这些说法,因此不将其作为事实陈述呈现。然而,它对已记录并经独立测试的行为的判断是明确的。
在以产品中立术语单独呈现相同行为时,Grok 得出了相同的结论。
文档化的功能发送了什么
RuntimeWire 将 Muse 的提供者端点重定向到本地捕获服务器,并检查客户端组装的精确请求。在具有隔离 Codex 主目录的干净工作区中,Muse 在第一次提供者请求的开发者消息中放入了合成全局 AGENTS.md 文件的完整内容。该提示并未要求 Muse 打开或导入该文件。
初始请求还包括为已植入个人 Codex skill 的元数据,包括其名称、路径和描述。Muse 将完整的 skill 正文推迟到模型调用 read_skill 工具时,届时正文出现在后续的提供者请求中。
使用 --no-foreign-personal-context 的配对捕获省略了 AGENTS.md 内容和个人 skill 元数据。该标志的命令行帮助将其描述为在该次运行中排除外来个人规则和技能。
RuntimeWire 还将行为对照 Meta 的实时 muse-spark-1.2-contributor 模型进行了测试。在默认运行中,模型遵循了来自个人 Codex 规则文件的合成指令。
在使用 --no-foreign-personal-context 的配对运行中,该指令不存在,模型给出了不同的回答。两次运行均正常完成,且都未在跟踪中显示文件工具调用。

muse-spark-1.2-contributor 的实时运行中,Muse 宣布其正在包含 Codex 个人规则并返回了 FOREIGN-RULE-CANARY-7319。配对的选择退出运行回答为 Unknown。图形:RuntimeWire;根据配对 JSONL 跟踪重建。)RuntimeWire 用已植入的 ~/.claude/CLAUDE.md 文件获得了相同的请求级结果。默认情况下,Muse 在第一次提供者请求中放入了 Claude Code 指令;当启用 foreign-personal-context 标志时则将其省略。
Codex 可以配置为识别备用的项目指令文件名,包括 CLAUDE.md,但 OpenAI 的文档称未添加到其后备列表的文件名在指令发现期间会被忽略。RuntimeWire 的 Muse 测试不需要可比的配置,并使用存储在所选工作区之外的个人文件。
这些文件包含的不仅仅是格式偏好
Codex 和 Claude Code 将这些文件用作持久的操作指令。
一名 OpenAI 的工程师可能会在为 Anthropic 客户编写的个人 CLAUDE.md 中合理地保留内部构建命令、私有包名或安全要求。Muse 会将该文件视为可重用上下文,并可以在未经工程师事先询问的情况下将其内容发送到 Meta。
OpenAI 的 Codex 文档 表示 Codex 在开始任何工作之前会读取 AGENTS.md。其示例包括测试命令、依赖项偏好和审批要求。全局文件默认为 ~/.codex/AGENTS.md,并适用于所有代码库。
Anthropic 的 Claude Code 文档 将 ~/.claude/CLAUDE.md 描述为跨项目的个人偏好存放位置。Claude 文件可以包含构建和测试命令、编码标准、架构决策、命名约定和工作流程指令。Anthropic 还记录了用于将另一个代理的配置作为一次性拷贝导入 Claude Code 的显式 /import 命令。
团队通常使用这些文件记录内部仓库布局、私有包名、部署命令、审查规则、问题追踪约定和组织上下文。它们不应包含凭证,但客户端不能假定每个用户都遵循了该做法。
一位以 Khavel_dev 发布评论的 Reddit 用户(查看时其评论标记为 11 分钟前)描述了专有数据方面的担忧:
这更糟糕的是 CLAUDE.md 通常包含的内容。我的文件里有架构决策、存放秘密的位置路径、内部 API 引用、部署配置。它基本上是一个项目地图。如果基于某个 contributor 定价层默认就把这些发到 Meta 的训练流水线,那对于任何处理专有内容的人来说都是一个真正的问题。对数据共享进行选择加入是可以接受的,默认选择退出就很可疑。

Muse 的兼容性功能跨越了一个可能令用户感到惊讶的边界:为一个供应商的客户端编写的材料会在该会话中未经显式导入操作就成为另一供应商模型的输入。

--no-foreign-personal-context 描述为在运行中排除外来个人规则和技能。图形:RuntimeWire;根据捕获的 CLI 输出重建。)测试未发现的内容
RuntimeWire 未观察到 Muse 在启动时自动打开竞争客户端的会话记录、认证文件、设置文件或无关的项目文件。Muse 有一个单独的会话导入功能,其捆绑的指令需要明确的用户请求。
Contributor 级别的问题
实时配对测试使用了 muse-spark-1.2-contributor,这是所测试 Muse 配置选择的模型。Meta 的定价文档 将其 Contributor 等级描述为一种折扣访问,以换取使用提示和完成结果来训练未来 Meta 模型的许可。
这就产生了一个 Meta 公开材料并没有明确回答的数据处理问题:当 Muse 在提供者请求中插入 Codex 或 Claude 指令文件时,Meta 是否将该插入内容视为用户提示的一部分以用于保留和训练目的?
RuntimeWire 验证了 Muse 将已植入指令传输到 Meta 的实时模型,且模型遵循了该指令。RuntimeWire 未发现 Meta 对测试文件进行保留或训练的证据。保留、审查和训练是 Meta 的独立问题。
RuntimeWire 向 Meta 询问以求澄清:
- Muse 默认加载哪些 Codex 和 Claude 文件;
- 是否存在持久性的 UI 设置可在所有未来会话中禁用该行为;
- 外部规则和技能元数据在 Contributor-tier 数据条款下如何分类;
- 这些文件是否会被保留或有资格用于模型训练;
- 在传输之前 Muse 是否会扫描导入内容以查找秘密;以及
- 为什么跨客户端导入默认启用,而不是要求明确同意。
Meta 在发稿时未予回应。若公司回复,RuntimeWire 将更新本文。
来源
- Meta's Muse Code configuration guide
- Meta's pricing and rate-limits documentation
- OpenAI's Codex instruction-file documentation
- Anthropic's Claude Code memory documentation
方法论
RuntimeWire 测试了由 Meta 安装程序分发的 Linux ELF 构建,标识为 muse-bin-0.1.0-R708.1。
SHA-256
50937b6470cd0edf28eb683c352a5e7af3bcb1b015cd9a3b21dbf79d22af8182
本报道结合了静态字符串与资源检查、Muse 自身的命令行输出、配对的本地提供者捕获、配对的实时 Meta 请求以及负对照文件系统跟踪。Canary 值为合成,仅为本次测试创建。未使用任何生产凭证、源代码或第三方会话内容作为测试数据。
本文中所有行为性断言仅适用于 Muse Code 0.1.0-R708.1,测试时间为 2026年8月8日至9日。Meta 可能在后续版本中更改该行为。