{"slug": "muse-code-loads-codex-and-claude-rules-by-default-we-traced-what-gets-sent-to", "title": "Muse Code Loads Codex and Claude Rules by Default. We Traced What Gets Sent to Meta", "summary": "Meta's Muse Code automatically loads machine-wide personal rules created for Codex and Claude Code into provider requests, as documented in its configuration guide. RuntimeWire captured the first provider request and confirmed that the complete contents of a personal Codex AGENTS.md file were included, and a paired live test with Meta's muse-spark-1.2-contributor model showed the model followed a synthetic instruction from the file unless the --no-foreign-personal-context flag was used. The behavior raises questions about how imported instructions are treated under Contributor-tier data terms.", "body_md": "Meta's Muse Code automatically loads machine-wide personal rules created for Codex and Claude Code. Meta documents the behavior in its [configuration guide](https://dev.meta.ai/docs/muse-code/configuration): \"Your machine-wide user rules always load.\"\n\nThe Muse terminal also prints a startup notice when it finds Codex rules: `Including your Codex personal rules - manage with /settings.`\n\nIt does not display an interactive permission request. Users can exclude the files from a run with `--no-foreign-personal-context`\n\n.\n\nRuntimeWire captured the first provider request generated by Muse and confirmed that the complete contents of a personal Codex `AGENTS.md`\n\nfile were included. The file was stored outside the selected Muse workspace. A separate capture produced the same result with a personal Claude Code `CLAUDE.md`\n\nfile.\n\nIn a paired live test, Meta's `muse-spark-1.2-contributor`\n\nmodel followed a synthetic instruction placed in the Codex file. When RuntimeWire enabled the opt-out flag, the instruction disappeared and the model returned a different answer.\n\nThe tests document how Meta's disclosed compatibility feature operates at the provider boundary. They also raise a question Meta's documentation does not answer: how are instructions imported from competing products treated under Contributor-tier retention and model-training terms?\n\n*(A captured Muse provider request containing a planted Codex rule)*\n\n*Muse placed the full contents of a planted Codex *`AGENTS.md`\n\nfile 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.\n\n### Why it matters\n\nMuse'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.\n\n### What the documented feature sends\n\nRuntimeWire redirected Muse's provider endpoint to a local capture server and inspected the exact request assembled by the client. In a clean workspace with an isolated Codex home directory, Muse placed the complete contents of a synthetic global `AGENTS.md`\n\nfile inside a developer message on the first provider request. The prompt did not ask Muse to open or import the file.\n\nThe initial request also included metadata for a planted personal Codex skill, including its name, path and description. Muse deferred the full skill body until the model invoked the `read_skill`\n\ntool, at which point the body appeared in a later provider request.\n\nA paired capture using `--no-foreign-personal-context`\n\nomitted the `AGENTS.md`\n\ncontents and the personal skill metadata. The flag's command-line help describes it as excluding foreign personal rules and skills from that run.\n\nRuntimeWire separately tested the behavior against Meta's live `muse-spark-1.2-contributor`\n\nmodel. In the default run, the model followed a synthetic instruction from the personal Codex rules file.\n\nIn the paired run using `--no-foreign-personal-context`\n\n, the instruction was absent and the model answered differently. Both runs completed normally, and neither trace showed a file-tool call.\n\n*(In a live run using *`muse-spark-1.2-contributor`\n\n, Muse announced that it was including Codex personal rules and returned `FOREIGN-RULE-CANARY-7319`\n\n. The paired opt-out run answered `Unknown`\n\n. Graphic: RuntimeWire; reconstructed from paired JSONL traces.)\n\nRuntimeWire obtained the same request-level result with a planted `~/.claude/CLAUDE.md`\n\nfile. Muse placed the Claude Code instruction in the first provider request by default and omitted it when the foreign-personal-context flag was enabled.\n\nCodex can be configured to recognize alternate project instruction filenames, including `CLAUDE.md`\n\n, but OpenAI's documentation says filenames not added to its fallback list are ignored during instruction discovery. RuntimeWire's Muse tests required no comparable configuration and used personal files stored outside the selected workspace.\n\n### These files can hold more than formatting preferences\n\nCodex and Claude Code use these files as persistent operating instructions.\n\nAn engineer at OpenAI could reasonably keep internal build commands, private package names or security requirements in a personal `CLAUDE.md`\n\nwritten for Anthropic's client. Muse treats that file as reusable context and can send its contents to Meta without first asking the engineer.\n\n[OpenAI's Codex documentation](https://developers.openai.com/codex/agent-configuration/agents-md) says Codex reads `AGENTS.md`\n\nbefore doing any work. Its examples include test commands, dependency preferences and approval requirements. The global file defaults to `~/.codex/AGENTS.md`\n\nand applies across repositories.\n\n[Anthropic's Claude Code documentation](https://code.claude.com/docs/en/memory) describes `~/.claude/CLAUDE.md`\n\nas 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`\n\ncommand for bringing another agent's configuration into Claude Code as a one-time copy.\n\nTeams 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.\n\nA Reddit commenter posting as Khavel_dev, whose comment was marked 11 minutes old when viewed, described the proprietary-data concern:\n\nWhat makes this worse is what CLAUDE.md typically contains. Mine has architecture decisions, paths to where secrets live, internal API references, deployment configs. It's basically a project map. If that's going to Meta's training pipeline by default because of some contributor pricing tier, that's a real problem for anyone working on anything proprietary. Opt-in for data sharing would be fine, opt-out by default is sketchy.\n\nMuse'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.\n\n*(Muse's own help describes *`--no-foreign-personal-context`\n\nas excluding foreign personal rules and skills from a run. Graphic: RuntimeWire; reconstructed from captured CLI output.)\n\n### What the tests did not find\n\nRuntimeWire did not observe Muse automatically opening rival-client session transcripts, auth files, settings files or unrelated project files at startup. Muse has a separate session-import feature whose bundled instructions require an explicit user request.\n\n### The Contributor-tier question\n\nThe live paired test used `muse-spark-1.2-contributor`\n\n, the model selected by the tested Muse configuration. [Meta's pricing documentation](https://dev.meta.ai/docs/pricing-rate-limits/) describes its Contributor tier as discounted access given in exchange for permission to use prompts and completions to train future Meta models.\n\nThat 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?\n\nRuntimeWire verified that Muse transmitted the planted instruction to Meta's live model and that the model followed it. RuntimeWire found no evidence that Meta retained or trained on the test files. Retention, review and training are separate questions for Meta.\n\nRuntimeWire asked Meta to clarify:\n\n- which Codex and Claude files Muse loads by default;\n- whether a persistent UI setting disables the behavior for all future sessions;\n- how foreign rules and skill metadata are classified under Contributor-tier data terms;\n- whether those files are retained or eligible for model training;\n- whether Muse scans imported content for secrets before transmission; and\n- why cross-client import is enabled by default instead of requiring affirmative consent.\n\nMeta did not respond by publication time. RuntimeWire will update this article if the company responds.\n\n### Sources\n\n### Methodology\n\nRuntimeWire tested the Linux ELF build distributed by Meta's installer as `muse-bin-0.1.0-R708.1`\n\n.\n\n```\nSHA-256\n50937b6470cd0edf28eb683c352a5e7af3bcb1b015cd9a3b21dbf79d22af8182\n```\n\nThe 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.\n\nAll behavioral claims in this article are scoped to Muse Code `0.1.0-R708.1`\n\n, tested August 8-9, 2026. Meta may change the behavior in later builds.", "url": "https://wpnews.pro/news/muse-code-loads-codex-and-claude-rules-by-default-we-traced-what-gets-sent-to", "canonical_source": "https://runtimewire.com/article/exclusive-muse-code-sends-codex-and-claude-instructions-to-meta-by-default", "published_at": "2026-08-09 05:20:05+00:00", "updated_at": "2026-08-09 09:58:10.480909+00:00", "lang": "en", "topics": ["ai-tools", "ai-policy"], "entities": ["Meta", "Muse Code", "Codex", "Claude Code", "RuntimeWire", "muse-spark-1.2-contributor"], "alternates": {"html": "https://wpnews.pro/news/muse-code-loads-codex-and-claude-rules-by-default-we-traced-what-gets-sent-to", "markdown": "https://wpnews.pro/news/muse-code-loads-codex-and-claude-rules-by-default-we-traced-what-gets-sent-to.md", "text": "https://wpnews.pro/news/muse-code-loads-codex-and-claude-rules-by-default-we-traced-what-gets-sent-to.txt", "jsonld": "https://wpnews.pro/news/muse-code-loads-codex-and-claude-rules-by-default-we-traced-what-gets-sent-to.jsonld"}}