MUONMUONDocs

Quickstart

Your first mission

This walks the same path the app's own first-run wizard does: open MUON, pick a workspace, connect one coding agent, run a real mission, watch the crew work, and decide the gates it files. Nothing here is destructive by default — MUON's own seeded first task only adds files, it never edits or deletes anything you already have.

  1. Open the app and pick a workspace

    Launch MUON (see Install if you haven't yet) and choose the folder you want the crew to work in. This becomes the chat's workspace — memory, blast-radius, and every path in the run are scoped to it.

  2. Connect a vendor

    The first-run wizard checks Claude Code, Codex, Cursor, and OpenCode separately for installed vs. authenticated, and gives one concrete next action for whichever is missing. You never hand MUON a token — you log in to the vendor's own CLI, and MUON only observes readiness.

    From a terminal, the same check is:

    muon onboard
  3. Run a mission chat

    Type what you want done into the chat. MUON's orchestrator plans the work, dispatches it to the fleet, and reports back — the gates stay yours. No task ready in mind? MUON can seed a tiny, safe sample (adds a greet(name) helper and a test) so you can watch the whole loop without inventing one:

    muon quickstart                    # seed + dispatch a safe sample task
    muon chat --workspace <dir>        # or start a real mission yourself
  4. Watch the crew

    Open the desktop's Crew Topology tab (⌘K → “Open crew topology”) to see who is doing what: one node per vendor lane, nested subagents drawn under their parent, and peer edges only where two jobs actually exchanged an addressed message. From the terminal:

    muon crew roles --chat <id>     # who holds which role, and why
    muon crew coord --chat <id>     # peer messages, file claims, conflicts
    muon dispatch status            # active jobs across the fleet

    Peer messages are rendered as explicit “Agent text · untrusted” — another agent's words are evidence, never an instruction and never something that can approve or dispatch anything on its own.

  5. See the moat: the pre-edit hero

    Before an agent edits a target, MUON fuses its code blast-radius with the human-confirmed memory anchored to it — prior decisions, contested proposals, and any live cross-agent activity on the same target. It auto-populates from the task you just ran. From the terminal:

    muon context muon-hello.ts   # or any symbol / file / module path

    Trusted decisions show their full text. Contested proposals show existence-only until you explicitly ask to read them — an unvetted note can never sneak into an agent as if it were settled fact.

  6. Approve, review, merge

    When an agent needs to cross a boundary — an edit outside the expected surface, a network call, a merge — MUON files a gate and waits. Desktop notifications deep-link to the full review; they never let you approve directly from the notification itself. Every field of the request (exact action, scope, consequence, bound evidence) has to be visible, and truncated text can never be approved.

    A merge gate in particular is graph-certified when possible: MUON reviews the diff itself and either certifies it or marks specific files REVIEW BLIND (new or unindexed files, or a stale index) that need a human's own read before the merge can go through. From the terminal:

    muon approve list
    muon approve review --approval-id <id>     # exact artifact digest + blind files
    muon approve resolve --approval-id <id> --status approved

Honest about full-auto

The desktop sidebar has a full-auto panel that turns red when armed — that color is deliberate: it is disabling a gate, and MUON wants that visible at a glance, not buried in a settings page. You can arm it for every lane or for specific vendor lanes only:

  • Off (default): “every approval waits for you.”
  • Armed, all lanes: “every approval resolves automatically. Egress and blocked merge reviews still ask.”
  • Armed, a subset of lanes: “checked lanes approve automatically; every other request still asks you.” A request MUON cannot attribute to a specific vendor lane is never covered by a partial selection — only the all-lanes checkbox does that.

Full-auto is standing operator consent, not a bypass: every auto-approval still goes through the same approval path a manual click uses, and it leaves a named receipt in the audit trail (the exact command or scope that was approved, redacted of secrets, with its risk level) — never a bare “auto-approved,” because a decision recorded without its subject isn't a reviewable one. See Governance for what full-auto can never cover.