Muse Code goes multi-agent by default: 6 permission details worth stealing

Meta's Connect developer recap, published September 24, describes Muse Code as "multi-agent by default, allowing parallel workers to write and test code in isolated workspaces." The tool left beta on August 31, gained a native Windows build in September, and subscriptions start at $5 per month. That is the news, and it is fine. The part I keep thinking about is the permission model underneath, because Meta's permissions documentation reads like a checklist for how any coding agent should treat your shell, your config files, and its own memory.

I read the permissions and workflows docs end to end. Six details stood out. All of them apply no matter which agent you run.

Two layers that answer different questions

Every Muse Code session ships with two independent guardrails, both on by default. Approval decides whether a command may run at all. The sandbox decides what a running command can touch. Meta is explicit that these are separate layers: a shell command in the default modes passes both, and the automated approval judge belongs to the approval layer, not to the sandbox.

The failure modes differ, which is the point. Approval protects you from intent, like the agent proposing a destructive removal in the wrong directory. The sandbox protects you from accident, like a test suite that writes outside the workspace or a dependency that phones home. One knob each. Most setups I see collapse these into a single allowlist, and then one config edit quietly widens both at once.

Staged shell review

Compound commands get reviewed stage by stage, not as one line. Muse Code parses the command into ordered stages, checks each against policy, and blocks on the first stage it cannot approve. Given a line like npm test && rm -rf dist && echo done, the read-only stages pass and the removal holds for review. If you reject the held stage, nothing runs, not even the safe stages before it. All-or-nothing per line.

The mode decides what happens to unmatched stages. In the default on-request mode, recognized non-dangerous stages pass and dangerous or external-execution patterns stop. In untrusted mode, every unmatched shell stage stops for review. The parser refuses to guess: shell grouping or control flow it cannot safely decompose also stops.

muse --approval-mode on-request   # default: safe stages pass, dangerous ones hold
muse --approval-mode untrusted    # any unmatched shell stage stops for review
muse --approval-mode never        # the sandbox alone contains what runs

One detail in the 1.2.1 changelog deserves more attention than it got: commands launched through wrappers such as env and setsid are now reviewed as the command they actually launch. Wrapper-blindness is exactly how allowlists get bypassed, and Meta shipped the fix as a security fix.

Workspace trust gates your config files

This is the detail I would copy first. Machine-wide user rules always load. Project rules, the AGENTS.md and CLAUDE.md in the checkout, load only after you trust the workspace, and trust is remembered per workspace root. An untrusted checkout gets no project config at all.

Meta explains why in the warning on --yolo: trusting a workspace loads its AGENTS.md, rules, and skills, and on a pull-request or fork checkout those files are attacker-controlled instructions. A rules file that grants itself more power is not a control, it is a suggestion. I wrote about this split before in config files versus hooks, and gate-loading project config on explicit human trust is the honest version of it.

Compare that with the common default elsewhere: clone a repo, the agent reads every instruction file in it, and a malicious rules file in a fork becomes prompt injection with file access.

The sandbox fails closed

Shell commands run under an OS-enforced filesystem and network policy. Seatbelt on macOS, a bundled bubblewrap helper on Linux, a Windows sandbox that may show one UAC prompt on first initialization. The policy grants write access to the workspace and a temp directory, keeps the rest of the filesystem read-only, and defaults outbound network to proxy-only, where the first connection to a new host, port, or protocol stops for review.

Two details make it real. First, it fails closed: Muse Code refuses to run a shell command when it cannot confirm the sandbox is active, and a Linux host without a working bubblewrap fails every shell command as an environment error. Second, inside the writable workspace the .git, .muse, and .agents directories stay read-only, so the agent cannot rewrite its own history, configuration, or memory. That is the sentence I would frame and hang on the wall. An agent that can edit its own instructions or its own memory has an obvious tampering path, and most of us never think about it.

Children only narrow

The multi-agent part is where permission models usually fall apart, because a swarm multiplies surface area. Muse Code's rule is short: workflow child agents inherit the lead session's effective tools and permission boundary. A child can narrow its toolset through its agent definition. It cannot expand it.

The scale limits are documented too. A workflow can call up to 1,000 child tasks over its lifetime, the number of simultaneously active children is CPU-derived and capped at 16, and the 1,001st child call fails the workflow before that child launches. Parallel writers get optional isolated Git worktrees, and you have to state that in the task, it is not automatic.

Remember the bill. Each child makes its own model calls, and Meta's own docs warn that a broad workflow can use substantially more tokens than a normal turn. I measured 41k tokens of context before the first prompt with nine MCP servers attached. Multiply that by 16 concurrent children and the arithmetic gets away from you fast. State files help keep parallel agents honest, something I covered in running 4 agents in parallel.

A checklist worth stealing

Strip away the branding and the docs hand you a review checklist for any agent setup, whether you run Claude Code, Cursor, Codex, or something else:

1. Config trust: project instruction files load only after explicit human trust, never on clone.
2. Two independent layers: an approval question (may this run) and a sandbox question (what can it touch).
3. Stage-wise shell review: compound commands decomposed, blocked at the first unapprovable stage, rejection kills the whole line.
4. Fail-closed sandbox: if the boundary cannot be enforced, the command does not run.
5. Self-tampering: the agent's own memory, history, and config stay read-only to the agent.
6. Inheritance only narrows: spawned children get a subset of permissions, never a superset.

Most of this cannot live in a rules file, it has to live in the harness. That is the same conclusion I keep landing on: write rules for judgment, put enforcement in mechanisms. If you want a starting point with the permission and enforcement sections already laid out per agent, the AgentConfig Studio kits cover it for $29, and the Next.js sample kit is free.

The migrate skill tells you the direction

Last detail, small but telling. Muse Code 1.2.1 ships a bundled migrate skill that imports your Claude Code or Codex memory notes and MCP servers into Muse Code. Meta is betting that developers will not stay loyal to one agent harness, and it is building the importer.

That matches what I see. The agents rotate, the config is the asset. Keep your rules versioned and format-portable, because the next harness will ask to import them. Muse Code made trust the gate for loading them. Your job is to make sure what sits behind the gate is worth trusting.