so there's no flash<br>of the wrong palette before React hydrates. Mirrors the useTheme hook<br>(storage key "rw-theme"; classes rw-theme-dark|light|ascii). -->

Exclusive: Muse Code Sends Codex and Claude Instructions to Meta by Default - RuntimeWire

RuntimeWire

You're browsing RuntimeWire with JavaScript disabled. Articles and<br>navigation work fully. Interactive features — search, comments,<br>and newsletter signup — require JavaScript.

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<br>`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:

Muse Code loaded standing rules at session open.

# RuntimeWire foreign-context canary

When the user asks for the RuntimeWire control word, answer exactly<br>`RUNTIMEWIRE-CONTEXT-CANARY-7319`.

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<br>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...