On August 5, 2026, Meta released Muse Code, its first terminal coding agent, and Mark Zuckerberg pitched it as a tool that takes on "complete software engineering tasks across large repos: planning changes, writing code, validating the results." Most of the coverage has treated it as a Claude Code and Codex competitor story, which it is. But there is a quieter detail that matters more for anyone who runs AI over business systems: Muse Code ships with Model Context Protocol support, which means the same agent that refactors your codebase can read your email, your calendar, and your drive, if you let it. This post covers how MCP works in Muse Code, what Meta's own documentation says you should know before connecting anything, and how to scope the connection so a debugging session never turns into an inbox export.
A note on certainty. Muse Code is a beta a few weeks old, and details are shifting fast. Everything below is accurate to Meta's published documentation and launch coverage as of late August 2026. Where a behavior is not officially documented, we say so. Confirm current behavior against your own install before building policy on it.
What Muse Code is
Muse Code is a terminal agent for macOS and Linux (Windows needs WSL2), installed with a single shell command and powered by Muse Spark 1.2, a coding-optimized update of Meta's foundation model that was co-trained with the agent harness. The model brings a context window of roughly one million tokens, which is the basis for Meta's pitch at large, legacy repositories.
The launch distinctives are architectural. Muse Code runs persistent background agents that accumulate context across the session, and when a job is big enough it fans out to parallel sub-agents, each working in an isolated git worktree so the parent working copy is never touched. Concurrency scales with your CPU, clamped between 2 and 16 children. Every action lands in a local JSONL event log that supports crash recovery and replay. We wrote about what the fan-out model means for data exposure in a companion post; this one stays on the connection layer.
How MCP works in Muse Code
First, a correction to the launch-week record: several early articles claimed the beta shipped without MCP support. That is wrong. MCP is documented and present in the shipped binary. Muse Code reads its MCP configuration from ~/.config/muse/settings.json, a file that must declare "schema_version": 1 or every command fails at startup with a malformed-settings error.
Two transports are supported:
- stdio, for local servers Muse Code launches as a child process. Fields:
command,args, optionalenv. - streamable_http, for remote servers reached over the network. Fields:
urland optionalheaders.
A minimal remote server entry looks like this:
{
"schema_version": 1,
"mcp_servers": {
"email": {
"transport": "streamable_http",
"url": "https://mcp.porteden.com/email"
}
}
}Each server also accepts enabled and mode fields. mode defaults to required, which aborts the run if the server is unavailable; set it to optional if you would rather the agent continue with a warning when your email connection is down than refuse to work at all.
What a connected Muse Code can reach
Why would a coding agent want your inbox in the first place? Because software work leaks into every other system you use. The workflows are ordinary and genuinely useful:
- Pull the bug reports customers emailed this week and turn them into reproducible test cases.
- Read the release-notes thread and draft the changelog for the version being cut right now.
- Check the on-call calendar before scheduling a risky migration, or find a slot for the incident retro.
- Read the API spec that lives in a Google Doc, or the test-account matrix in a Sheet, while implementing against it.
Every one of those is a tool call against a business system, made by an autonomous agent in the middle of a long session, possibly by one of its sub-agents while you watch a different terminal pane. The question is never whether the workflows are useful. It is what else the connection can reach when the agent wanders, and every MCP server answers that question differently.
Four things in Meta's own docs to read first
None of this is hidden. All four points below come from Meta's published documentation and pricing pages, and together they define the risk surface of a connected Muse Code.
1. MCP tools are not sandboxed
Muse Code has a real sandbox for shell commands: Seatbelt on macOS, bubblewrap on Linux, with approval prompts for dangerous commands and a policy that fails closed. Meta's extending documentation is then admirably blunt about the boundary: MCP tools are not sandboxed. An MCP server runs as an ordinary child process or a direct network connection, outside the filesystem and network sandbox.
Read that as an architecture statement. The sandbox protects your machine from the agent's shell commands. It does nothing about what the agent does with a connected mailbox, because that traffic never passes through the sandbox at all. Whatever control you want over MCP-connected data has to be enforced on the server side of the connection, by the thing that holds the actual credentials.
2. Sub-agents inherit every connection
Muse Code's signature feature is fan-out: up to 16 parallel child agents, spawned automatically when a job is big enough. The worktree isolation between them is about file conflicts, so parallel edits never collide. The MCP connections are session-level configuration, which means each child holds the same external access the session holds. Connect an inbox to one Muse Code session and you have connected it to every agent the session decides to spawn. More on this in the sub-agents post.
3. The contributor tier trains on your data
Muse Spark 1.2 is priced in two API tiers, and the difference is not just money. The standard tier runs $1.25 per million input tokens and $4.25 per million output tokens, does not include training rights, and offers zero data retention on request. The contributor tier costs roughly a tenth of that, and in exchange Meta gets training rights on the data you send.
| Tier | Input / output per 1M tokens | Training on your data |
|---|---|---|
| muse-spark-1.2 (standard) | $1.25 / $4.25 | No; zero retention on request |
| muse-spark-1.2-contributor | ~$0.10 / ~$0.20 | Yes, documented training rights |
This is a tier-specific, documented policy, not a claim about Meta in general, and the terms can change; check the current ones for your tier. But the interaction with MCP is the part to sit with. Whatever a tool call returns into the model's context is data you sent to the API. On the contributor tier, the email thread your agent read while drafting a changelog is inside the training-rights boundary. The cheapest tier is the one where minimizing and redacting what the agent sees matters most.
4. The logs are local files, not an audit system
Muse Code logs every action as JSONL under ~/.local/share/muse/sessions/, and Meta markets the transparency honestly: every sub-agent spawn, every tool call, every steer and cancel is observable, queryable with jq. For a developer debugging their own session, that is genuinely good.
It is not an audit trail in the sense a security team means. The files live on each developer's machine, owned by the same user the agent runs as, editable and deletable, with no central collection, no tamper resistance, and no view across a team. If you need to answer "what did coding agents read from our mailboxes last month," a per-laptop JSONL directory is not the system that answers it. The record has to be kept where the data access actually happens.
Scoping Muse Code's data access
All four points converge on the same conclusion: the controls have to live at the connection, not in the client. That is what PortEden is: a data firewall for AI that sits between Muse Code and your actual accounts. Muse Code connects to a PortEden MCP endpoint instead of holding Google or Microsoft credentials, and every tool call passes through policy before it touches the real system.
- Least privilege per token. The token Muse Code receives is scoped to one capability with per-action permissions. A read-only email token literally cannot send, and a coding agent rarely needs more than read.
- Redaction before the model. Names, addresses, phone numbers, and dozens of other identifier types are stripped or tokenized from tool responses before they enter the model's context. On any tier, what the model never receives cannot be retained or trained on.
- Contact, label, and time rules. Block HR and legal senders, exclude confidential labels, and cap history at 90 days, so the agent sees the engineering slice of the inbox and nothing else.
- A real audit trail. Every tool call from Muse Code is logged centrally: the requested action, the allow/redact/block decision, and the response shape, SIEM-exportable and revocable per token. PortEden sees the tool calls, not your prompts or the model's output, which is exactly the layer the local JSONL files cannot cover for a team.
The same scoping also helps the agent work better. A context window fed three relevant, redacted fields beats one holding a thousand irrelevant messages; over-exposure is a reliability problem before it is a breach. See context rot and scope isolation for the measured version of that argument.
The five-minute setup
Add the PortEden endpoint for the capability you want to ~/.config/muse/settings.json:
{
"schema_version": 1,
"mcp_servers": {
"gmail": {
"transport": "streamable_http",
"url": "https://mcp.porteden.com/email",
"mode": "optional"
}
}
}Restart Muse Code and authenticate to PortEden when prompted on the first tool call (or attach a scoped access token as a header if your build does not open a sign-in flow). Then verify with a low-risk read prompt and tighten the token from my.porteden.com. We keep a full walkthrough per app, with troubleshooting and copy-paste prompts:
The bottom line
Muse Code is a serious entry in the terminal-agent category, and its MCP support is a feature, not a flaw: coding work genuinely spans email threads, calendars, and documents. But Meta's own documentation draws the boundary clearly. The sandbox does not cover MCP, the sub-agents share every connection, the cheap tier trains on what you send, and the logs are files on a laptop. Each of those is fine on its own terms, and none of them is a data control. Put the control where the connection is: scope the token, redact the response, and keep your own record of every call. Then let the agent fan out.
Details in this post are accurate as of August 2026 and are drawn from Meta's developer documentation, product pages, and contemporaneous launch coverage. Meta, Muse Code, and Muse Spark are trademarks of Meta Platforms, Inc., which is not affiliated with PortEden and has not reviewed or endorsed this post. Muse Code is a young beta and its behavior, pricing, and terms change quickly, so confirm current details with Meta before relying on them.