Meta's Muse Code ships your personal CLAUDE.md to Meta by default

Go look at your ~/.claude/CLAUDE.md right now. Mine has internal package names, a build command with a host in it, and notes about which credentials live where. I wrote it assuming exactly one reader.

RuntimeWire published traced request captures on August 9 showing Muse Code placing the complete contents of a personal ~/.codex/AGENTS.md, and separately a personal ~/.claude/CLAUDE.md, into the developer message of its very first provider request. No file-tool call. No interactive permission prompt. Even when those files sit entirely outside the selected workspace.

Meta documents it. "Your machine-wide user rules always load." The terminal prints a passive notice. There's an opt-out flag, --no-foreign-personal-context, which RuntimeWire confirmed removes the content in paired live runs against muse-spark-1.2-contributor. So this isn't a bug and it isn't hidden, exactly. It's a default nobody would choose if asked.

The unanswered question is retention. Meta hasn't explained how instructions imported from competing products are handled under Contributor-tier retention and training terms. Your CLAUDE.md is a document you wrote to configure a different vendor's agent, and it's now sitting in Meta's request logs under terms that don't obviously contemplate that case.

This is the third instruction-file failure in one week, which is what makes it a pattern instead of an incident.

Novee's Black Hat research, reported by Hackread, found the openai/codex repository itself running two Codex passes inside a single CI job sharing one checkout. A first pass manipulated by untrusted issue content could write an AGENTS.md that the second pass then loads as its own project instructions. OpenAI assigned no CVE and called it working-as-documented, so this is a configuration problem you fix yourself, not a patch you wait for.

And CVE-2026-54316 in Claude Code, per The Hacker News, turned Hugging Face's public download counter into an exfiltration channel that leaked an API key one character at a time, affecting 0.2.54 through 2.1.163. Anthropic rates it CVSS v4 6.0; NVD rates it CVSS v3.1 9.1. That gap is its own conversation. The companion finding, CVE-2026-12537 in Gemini CLI, carries CVSS v4 10.0: OS command injection in the container launcher via a crafted .gemini/.env, executing on the CI host before the sandbox starts. Fixed in 0.39.1 and run-gemini-cli 0.1.22.

Agent-written instructions, transmitted instructions, credentials leaking from next to instructions. The format's entire value proposition is that it's persistent, implicit, machine-wide, and read before any work happens. That's also the exact description of an ideal attack surface.

Tonight's work, and it's maybe twenty minutes: read your global instruction files and strip anything credential-adjacent. Move machine-wide config to per-project scope. Audit which of your installed agents read files outside their own directory. And never share a checkout between two agent passes in one CI job. Treat any agent-writable instruction file as attacker-controlled input on the next invocation, because that's what it is.