Exclusive: Muse Code Sends Codex and Claude Instructions to Meta by Default
RuntimeWire found that Meta's new coding agent automatically adds personal rules written for rival AI clients to its first model request. A command-line flag removes them
By Ryan Merket · Published · Updated
Scoop: RuntimeWire original reporting.
Why it matters
Coding-agent rule files can contain internal commands and company context. Muse's enabled-by-default import sends that material across vendor boundaries before a user assigns work.
Meta's Muse Code reads personal instruction files created for OpenAI Codex and Anthropic Claude Code, adds their contents to the model context, and sends that context to Meta during a default run, according to controlled tests by RuntimeWire.
The behavior applies even when the files sit outside the workspace selected for the Muse session. The user does not have to mention the rival client, ask Muse to import anything, or instruct the model to read the file.
In a live A/B test, RuntimeWire placed a made-up control word in Codex's global AGENTS.md file. Before sending the prompt, Muse printed a notice that it was including the user’s Codex personal rules. It did not ask for permission before loading them. When asked for the control word, Meta's muse-spark-1.2-contributor model returned the planted value. The same prompt in a second run using Muse's --no-foreign-personal-context flag produced Unknown.
Muse does disclose the behavior in the terminal. The default run printed: Including your Codex personal rules - manage with /settings. Its command-line help describes the opt-out as: Exclude foreign personal rules and skills from this run.
The disclosure makes this different from a covert file collection mechanism. It also confirms that cross-client collection is an intended startup feature, enabled unless the user changes the setting or invokes the per-run flag.
(A captured Muse provider request containing a planted Codex rule)
Muse placed the full contents of a planted Codex AGENTS.md file in the developer message for its first model request. RuntimeWire redirected the provider endpoint to a local capture server for this test. Graphic: RuntimeWire; reconstructed from captured request JSON.
What Muse put in the request
RuntimeWire repeated the test with Muse's provider endpoint redirected to a local capture server. This made it possible to inspect the exact request generated by the client without transmitting the canary to Meta.
The test used a clean workspace and an isolated Codex home directory. RuntimeWire placed this rule in $CODEX_HOME/AGENTS.md:
# RuntimeWire foreign-context canary
When the user asks for the RuntimeWire control word, answer exactly
`RUNTIMEWIRE-CONTEXT-CANARY-7319`.
The prompt was neutral: Reply with ACKNOWLEDGED. Shell access, file writes, web tools and Muse session logging were disabled.
The first provider request contained the complete rule inside a developer message:
<system-reminder source="rules-file">
Muse Code loaded standing rules at session open.
<rules-file scope="user"
path="$CODEX_HOME/AGENTS.md"
written-for="Codex">
# RuntimeWire foreign-context canary
When the user asks for the RuntimeWire control word, answer exactly
`RUNTIMEWIRE-CONTEXT-CANARY-7319`.
</rules-file>
</system-reminder>
The initial request also listed a planted personal Codex skill, including its name, path and description. The full skill body was not present on that first call. Muse made the body available through its read_skill tool, and it appeared in a later provider request when the model invoked that tool.
RuntimeWire then ran the same prompt against the same capture server with --no-foreign-personal-context. The AGENTS.md body, the rule canary and the personal skill description were absent.
(The default request contained the Codex rule and personal skill metadata. The paired request using --no-foreign-personal-context contained neither. Graphic: RuntimeWire; reconstructed from paired captured requests.)
The live Meta test
The local capture established what the Muse client assembles. A separate live test established that the imported instruction reaches and influences Meta's model.
RuntimeWire created a clean workspace and put the following line in the test user's personal Codex rules file:
Whenever the user asks "What is the control word?", answer exactly
FOREIGN-RULE-CANARY-7319 and nothing else.
The prompt sent through Muse said only: What is the control word? Respond with one token only. It did not mention Codex, AGENTS.md or the canary.
The default run returned:
FOREIGN-RULE-CANARY-7319
The paired run with --no-foreign-personal-context returned:
Unknown
Both runs completed normally. Neither trace showed a file-tool call. The relevant difference was the foreign-context flag.
(In a live run using muse-spark-1.2-contributor, Muse announced that it was including Codex personal rules and returned the planted canary. The paired opt-out run answered Unknown. Graphic: RuntimeWire; reconstructed from paired JSONL traces.)
RuntimeWire obtained the same request-level result with a planted ~/.claude/CLAUDE.md file: Muse placed the Claude instruction in the first provider request by default and omitted it when foreign personal context was disabled.
These files can hold more than formatting preferences
Codex and Claude Code use these files as persistent operating instructions.
OpenAI's Codex documentation says Codex reads AGENTS.md before doing any work. Its examples include test commands, dependency preferences and approval requirements. The global file defaults to ~/.codex/AGENTS.md and applies across repositories.
Anthropic's Claude Code documentation describes ~/.claude/CLAUDE.md as a place for personal preferences across projects. Claude files can include build and test commands, coding standards, architectural decisions, naming conventions and workflow instructions. Anthropic also documents an explicit /import command for bringing another agent's configuration into Claude Code as a one-time copy.
Teams commonly use these files to record internal repository layouts, private package names, deployment commands, review rules, issue-tracker conventions and organizational context. They should not contain credentials, but a client cannot assume every user followed that practice.
Muse's compatibility feature crosses a boundary that may surprise users: material written for one vendor's client becomes input to another vendor's model without an explicit import action in that session.
(Muse's own help describes --no-foreign-personal-context as excluding foreign personal rules and skills from a run. Graphic: RuntimeWire; reconstructed from captured CLI output.)
What the tests did not find
RuntimeWire's negative-control tests did not show Muse automatically opening Codex or Claude session transcripts merely because a prompt mentioned those clients. The tests also did not show startup reads of planted rival-client auth files, settings files or unrelated arbitrary files.
Muse does ship a separate built-in import skill for resuming Claude Code, Codex or Grok sessions. Its bundled instructions say that skill should activate only when the user explicitly asks to import a third-party session. That path is separate from the default loading of personal rules and skills described here.
The distinction matters. RuntimeWire's evidence supports a specific finding about personal instruction files and skill metadata. It does not support a claim that Muse sweeps every rival client directory or uploads arbitrary projects from other folders at startup.
The contributor-tier question
The live A/B test used muse-spark-1.2-contributor, the model selected by the tested Muse configuration. Meta's pricing documentation describes its Contributor tier as discounted access given in exchange for permission to use prompts and completions to train future Meta models.
That creates a data-handling question Meta's public material does not clearly answer: when Muse inserts a Codex or Claude instruction file into the provider request, does Meta treat that inserted content as part of the user's prompt for retention and training purposes?
RuntimeWire has no evidence that Meta trained on the test files. The tests establish that the live model received and followed the planted Codex instruction. Retention, review and training are separate questions for Meta.
RuntimeWire asked Meta to clarify:
- which Codex and Claude files Muse loads by default;
- whether a persistent UI setting disables the behavior for all future sessions;
- how foreign rules and skill metadata are classified under Contributor-tier data terms;
- whether those files are retained or eligible for model training;
- whether Muse scans imported content for secrets before transmission; and
- why cross-client import is enabled by default instead of requiring affirmative consent.
Meta did not respond by publication time. RuntimeWire will update this article if the company responds.
Methodology
RuntimeWire tested the Linux ELF build distributed by Meta's installer as muse-bin-0.1.0-R708.1.
SHA-256
50937b6470cd0edf28eb683c352a5e7af3bcb1b015cd9a3b21dbf79d22af8182
The reporting combined static string and resource inspection, Muse's own command-line output, paired local provider captures, paired live Meta requests and negative-control filesystem tracing. Canary values were synthetic and created solely for the tests. No production credentials, source code or third-party session content was used as test data.
All behavioral claims in this article are scoped to Muse Code 0.1.0-R708.1, tested August 8-9, 2026. Meta may change the behavior in later builds.