Repository navigation
Support Meta Muse Code (muse) as an external provider #258
Description
Current scope
Add Meta Muse Code (muse) as an external provider with read-only and isolated-write modes (Eric, 2026-11-06). Muse Code 1.4.14 is installed and logged in on studio1, and muse is on pro14.
Acceptance:
- Every flag in the adapter comes from the real
muse --helpandmuse exec --help, and the catalog records the version. - Read-only and write modes are measured with an escape test, and follow the rules in Add isolated-write to the external providers, with an opt-in for unconfined ones #263.
- Model proof follows
provider-dispatch.md. A registry family is optional, and no default role changes. - A live gate runs one read-only lane and one writer lane through the runner.
Execution brief
Unit of the 2026-11-06 batch, after #263.
Support Meta Muse Code (muse) as a read-only external provider, so a Muse model can sit on the interrogate reviewers and arena runners panels as a fourth family. Happy to be told it does not belong, or belongs in another shape.
For context, mattvv/claude-brain already runs a three-family review council with Sol, Grok and Muse (muse-wonder-1.0). It reaches Muse through CLIProxyAPI. A pstack lane would run Meta's own CLI instead.
Proposed adapter
This maps the adapter contract to muse exec --json. The flags come from a third-party wrapper (muse-codes 0.1.8), not from Meta's docs. They are not yet checked against a real muse exec --help.
| Contract field | Proposed value |
|---|---|
executable |
muse |
launch.prompt |
file: --prompt-file <promptPath> |
effortIn |
flag: --reasoning-effort (none minimal low medium high xhigh ultra) |
launch.supports |
read-only only |
| Read-only argv | --disable-write --disable-shell --disable-web-tools --no-foreign-personal-context --worktree off --workspace <cwd>. Keep the OS sandbox on. Never pass --yolo, --trust-workspace, --disable-sandbox. |
parse |
JSONL MuseRecord envelopes, dispatched on payload_type. Final text from run.terminal.completed. Failures from other run.terminal.* reasons and from task.lifecycle (failed, rejected, cancelled). |
proof |
required: run.model.configured.model_id |
| Usage and cost | null: the events carry no model token counts |
environment |
allowlist: base names, plus the prefixes that the CLI reads (to be measured) |
Registry: an optional muse-wonder family (muse:muse-wonder-1.0). Possibly also muse-spark-1.3 as a cheaper model.
Open questions (need a real muse and a Muse Code login)
- Preflight. Is there a command that proves the login and lists the models, like
grok models? The wrapper shows nologin,statusormodelssubcommand. - Headless approvals. Does a tool call that needs approval block a headless run? If so, does
--user-input-auto-resolveor the sandbox prevent that without--disable-approval? - Read tools. Which read and search tools remain with
--disable-shellset? A reviewer lane needs them. - State paths and config. Where does the CLI keep its login and session logs? Which host, workspace or repository config does it load in a lane? This is for the catalog notes, as for Amp in Support Amp as an external provider #158.
I can capture muse --help, muse exec --help and one recorded read-only run as fixtures if that helps.
Activity
ericlitman commentedon Nov 6, 2026
We'll take this. We have Muse Code installed and logged in, so we'll measure the real
muse execflags ourselves rather than rely on the wrapper's. One change from the proposal: we're adding write access to the providers, so a Muse lane can serve as an interrogate adversary that runs code, not only as a read-only reviewer. We'll link the PR here.[-]Support Meta Muse Code (`muse`) as a read-only external provider[/-][+]Support Meta Muse Code (`muse`) as an external provider[/+]feat(runner): record Muse Code 1.4.14 help and event streams
feat(runner): enable measured writers and add the Muse Code provider
feat(runner): verify provider writers and a Muse reader from the inst…
chore: release the provider writers and Muse as 1.18.0
chore(runner): drop a comment that repeats muse's preflight code
ericlitman commentedon Nov 6, 2026
PR: #268
fix(runner): pass META_API_KEY to Muse lanes and accept its preflight
fix(verify): link the operator's Muse config into the run state
Merge pull request #268 from ericlitman/feat/263-provider-writers
ericlitman commentedon Nov 6, 2026
Batch 262 closeout for this issue (full record: https://github.com/mobilyze-llc/docs/blob/main/projects/open-pstack/records/2026-11-06-batch-262/closeout.md):
#258: Support Meta Muse Code (
muse) as an external providerOriginal text: Grimnoth's proposal for a read-only adapter (proof from
run.model.configured, usagenull, an optionalmuse-wonderfamily, four open questions). The scope was rewritten on 2026-11-06 after Eric's words "that also opens up muse - we have it, and it's logged in". Shipped in #268.muse --helpandmuse exec --help: done as written (recorded fixtures)..git).provider-dispatch.md, optional family, no default change: done as written; proof is pinned argv becauserun.model.configuredonly echoes the request; usage comes fromrun.usage; no family registered.META_API_KEY(0e3d85b, which also acceptsmuse usage's "No subscription allowance (api_key)" as an API-key login), and the verifier hid the operator's Muse config by redirectingXDG_CONFIG_HOME(eefdd1f, which now symlinks the operator'ssettings.jsonandauth.jsoninto run state).Grimnoth's open questions: preflight answered (
muse usage); headless approvals answered (--approval-mode never --approval-judge offreturns a refused tool to the model); read tools under--disable-shelland full state and config paths not settled beyondsettings.jsonandauth.json. Also unverified from #268: MCP and plugin suppression, workspace switching, whether--reasoning-effortoverrides per-model effort, and dsh 0.2.1-rc.2's SIGTERM,.envand session-log behaviour. Reader addition.