Connecting Meta's Muse Code to your AI workers

Q: How do I connect Muse Code to my WorkerKit workers?

Add https://mcp.workerkit.ai/workers as a streamable_http server in ~/.config/muse/settings.json, with a bearer key created at /fleet-access in the headers field. The public catalog at https://mcp.workerkit.ai/directory needs no key at all. Only an account admin can create fleet keys.

Meta's Muse Code shipped with MCP support. Point it at the WorkerKit MCP server and the coding agent can read, run and schedule your AI workers.

Meta released Muse Code in beta on August 5, 2026: a terminal coding agent that plans changes, writes code and validates the results across large repositories, powered by the coding-focused Muse Spark 1.2 model. It joins Claude Code and OpenAI's Codex CLI in the category of agents that live where software gets made.

This post is about what sits just outside that category's edge. A coding agent's world is the repository, and Muse Code enforces that deliberately: an OS-enforced sandbox keeps its shell actions inside the workspace. But most of a shipped feature's life happens outside the repo, in inboxes, calendars, CRMs and monitoring, and that work does not stop when the terminal session ends.

Muse Code shipped with MCP support in its first beta, and WorkerKit runs a hosted MCP server. Connecting the two takes one settings block, and it gives the coding agent a second kind of reach: not into your apps, but into a fleet of AI workers that hold their own scoped access and keep working after the session closes.

What Muse Code is, briefly

The facts that matter for this post:

A terminal agent for macOS and Linux (Windows needs WSL2), installed with a single curl command, no Node or Python required.
It fans big jobs out to sub-agents working in parallel in isolated git worktrees, so the parent working copy is never touched.
Persistent background agents build context across the whole session, and every action is logged as plain JSONL you can query with jq.
Project rules live in AGENTS.md, seeded by muse init, with a fallback to CLAUDE.md for compatibility. It can also import skills from an existing .claude/skills directory.
MCP is supported in the shipped beta. Several launch-day articles claimed otherwise; they were wrong. Servers are configured under mcp_servers in ~/.config/muse/settings.json, over stdio or streamable HTTP.

Muse Spark 1.2 carries a 1M-token context window, which matters later in this post: reading fifty run receipts in one session is not a squeeze.

The edge of the repository

Two boundaries define what a coding agent cannot do, and both are features rather than gaps. Side by side with an AI worker, the split is clean:

	Muse Code	An AI worker
Lives	In your terminal, inside one repo	Hosted, connected to your apps
Driven by	You, in a session	A schedule, a webhook, or a client
App credentials	None, by design	Its own, scoped per app
When the session ends	Work stops	Work continues
Parallelism	Sub-agents in git worktrees	A fleet, one firewall per worker

It has no reach into your business systems. Muse Code holds no credential for your email, your calendar or your CRM, and it should not. An agent whose job is editing code has no business holding a mailbox grant, and Meta's own docs are blunt about why caution is warranted: MCP tools run outside the sandbox that contains shell commands.

Nothing survives the session. Muse Code's persistent agents persist for the session, and its JSONL logs make a crashed session resumable. But nothing it sets in motion runs at 07:00 tomorrow. When the terminal closes, the work stops.

The standing jobs around a codebase, triaging the support inbox, briefing the team each morning, watching the numbers a deploy might move, belong to something built to run unattended. That is what a worker is, and the WorkerKit MCP server is how an MCP client reaches a fleet of them.

One settings block

Muse Code reads MCP servers from ~/.config/muse/settings.json. The file must carry "schema_version": 1, and WorkerKit's two endpoints slot in as remote servers. (For the full connector mechanics, both transports and the validation quirks, see Muse Code connectors.)

{
  "schema_version": 1,
  "mcp_servers": {
    "workerkit": {
      "transport": "streamable_http",
      "url": "https://mcp.workerkit.ai/workers",
      "headers": { "Authorization": "Bearer pe_mgr_..." },
      "mode": "optional"
    },
    "workerkit-directory": {
      "transport": "streamable_http",
      "url": "https://mcp.workerkit.ai/directory",
      "mode": "optional"
    }
  }
}

Three notes on that block:

The key comes from [/fleet-access](/fleet-access). Create it there, choose its scopes, and paste it as the bearer header. It is shown once, at creation. Muse Code documents static headers on remote servers; whether the beta also walks MCP's browser sign-in flow is not documented yet, so create the key by hand. A key added by hand keeps working either way.
`"mode": "optional"` is deliberate. Muse Code's default mode is required, which aborts a run when a server is unreachable. A coding session should survive a fleet hiccup, so mark both servers optional and let a failed connection be a warning.
The directory endpoint needs no key at all. It is the public kits catalog, reachable the way a crawler reaches it. If you only want research, add just that one and skip the sign-in entirely.

What a coding agent does with a fleet

The connection earns its place on ordinary days, in the gap between "the code changed" and "the world noticed".

Run the affected worker out of cadence. Say a worker built from the Engineering Pulse kit reads your GitHub each morning and digests pull requests needing review, stale branches and failing workflows. You just merged a change that renamed the workflows it watches, and its next scheduled run is tomorrow at 07:00, a bad time to learn the digest broke. The check is four calls, and Muse Code makes all of them without leaving the terminal:

Step	Call	What comes back
Find the worker	`workers_list`	Engineering Pulse, enabled, last run green
Run it about the change	`worker_run` with a prompt naming the rename	A run id
Watch it	`run_events`, polled every few seconds	Each step, with timing and outcome
Read the result	`run_get`	The receipt, and the digest it produced

Debug a worker where you already are. A worker's run went wrong after a deploy. run_events replays its steps in order with timings and outcomes, so "which call failed and with what" is answerable without opening a browser, and the fix is often in the repo you already have open.

Set schedules by describing them. "Every weekday at 07:30 in Europe/London" becomes a schedule through schedule_create, without anyone translating it into fields.

Check the directory before building bespoke automation. The anonymous endpoint searches the public kit catalog. Before Muse Code writes you a cron job and a pile of API glue for inbox triage, it can check whether a kit already does the job with permissions you can read, and hand you the install link.

Orchestrate at fleet scale. worker_run takes an optional prompt for that run, so the same research worker can be pointed at fifty subjects in one session, each run done the way the worker was built to do it. This is fleet orchestration, and a 1M-token context window is comfortable holding every receipt while it synthesises the results.

There is a symmetry worth seeing here. Muse Code fans out sub-agents into isolated worktrees because isolation is what makes parallel code changes safe. A fleet applies the same idea to business reach: each worker holds only its own job's app access, so parallel unattended work stays safe for the same reason. Worktrees for changes to one repo, workers for standing jobs across many systems.

Meta's warning, answered with scopes

Meta's documentation says plainly that MCP servers are not sandboxed: they run as ordinary processes or direct network connections, outside the boundary that contains shell commands. That is true of every MCP server, so the right question for any of them is what the credential can reach.

For this one, the answer is narrow by construction:

A fleet key grants no app access at all. No tool on the server reads a mailbox, a calendar or a CRM. Workers reach apps, under their own firewalls, contact rules and redaction, and a run prompt cannot widen any of them. The worst a leaked fleet key can do is bounded by its scopes, and revoking it touches nothing else.
Scopes are opt-in, and a sound first key is read-only. Start with readWorkers and readRuns: Muse Code can describe the fleet and everything it has done, and change nothing. Add runWorkers when you want it to do work. Withhold manageInstructions longest, because rewriting a worker's tested method is the largest grant on the list.
The server holds no state. No sessions, no stored secrets. It forwards a request, returns the answer, and forgets.

Manners worth putting in AGENTS.md

muse init seeds an AGENTS.md, and the fleet's session manners belong in it so every future session inherits them:

## WorkerKit fleet

- When watching a run, poll run_events every 3 to 5 seconds, never in a
  tight loop.
- A run that comes back "skipped" is a receipt with a reason on it, not an
  error. Report the reason.
- A refusal naming a scope means the key is too narrow. Ask for a wider key;
  do not retry.
- On a rate limit, back off for the time the response asks for.

The budgets behind those manners are counted per account, so other tenants of the hosted server never affect you.

What this is not

It is not app access for Muse Code. The coding agent never touches your mail, calendar or CRM. It talks to workers; workers talk to apps.
It is not autonomy by default. The key's scopes are the whole of the agent's reach, and the read-only first key is genuinely useful on its own.
It is not a paid feature. The connection costs nothing. What a client triggers is metered like any other run: tool calls count against your daily allowance, and model tokens are billed at provider list price with no markup. See /pricing.

FAQ

Does Meta's Muse Code support MCP servers?

Yes, in the beta that shipped on August 5, 2026, despite some launch coverage claiming otherwise. Servers are configured under mcp_servers in ~/.config/muse/settings.json, over stdio for local servers or streamable HTTP for remote ones, with static auth headers supported on the remote transport.

How do I connect Muse Code to my WorkerKit workers?

Add https://mcp.workerkit.ai/workers as a streamable_http server in ~/.config/muse/settings.json, with a bearer key created at /fleet-access in the headers field. The public catalog at https://mcp.workerkit.ai/directory needs no key at all. Only an account admin can create fleet keys.

Can Muse Code read my email or CRM through this connection?

No. A fleet key manages workers and grants no access to any connected app. Only workers reach apps, under their own app firewall and contact rules, and nothing a coding agent sends in a prompt can widen them.

Does this work on Windows?

Muse Code itself has no native Windows build and requires WSL2. The WorkerKit side is hosted, so there is nothing to install for it: any environment that runs Muse Code can reach mcp.workerkit.ai.

Do I need a paid WorkerKit plan to use Muse Code with it?

No. The connection is not a paid feature. Runs a coding agent triggers are metered exactly like scheduled ones: tool calls against your plan's daily allowance, model tokens at provider list price with no markup.