Harnesses

Harnesses provides operation details, configuration and session entry points even when no repositories are watched. All six harness cards use the existing provider registry plus the versioned operations/readiness catalog. Factory delivery filters and the saved native-provider preference remain independent.

Binary status, reported integration capabilities, configured harness and observed bound session are different observations. An installed binary does not prove credential readiness or that an agent is bound to a team. A positive capability flag does not create a page or authorize a write.

Claude has the implemented native surfaces recorded in the registry. Codex has a configuration summary, configuration, MCP, plugins and read-only Plans adapters, with separate nested action guards. Copilot, OpenCode, Pi and Muse Code have no dedicated settings adapters in this registry; their CLI/integration capabilities and shared Teams/Bridge operations remain separate. Page availability intersects the required catalog's availability, exact adapter identity and access with the checked-in adapter and both native capability classifications. Missing, malformed, failed, expired or mismatched catalog data grants no native access. Canonical routes, compatibility aliases, detail routes, dashboard destinations and native API calls use this restriction. A writable legacy editor without a read-only presentation does not mount when access is narrowed to read-only; nested MCP/plugin mutations remain separately guarded.

Choose a native page for its explicit harness without changing the saved global preference. Use Teams and launch planning for a manual agent, review the current selected-slot plan, and invoke launch as a separate authenticated action. Bridge provides live-session inspection. Selecting Harnesses or navigating to a plan does not start automatic dispatch, launch an agent or grant agent approval.

Each card classifies ten operations as supported, conditional, unsupported or unknown and lists the conditions. Native feature counts do not determine operating support. Conditional support still requires current identity, workspace and approval authority; navigating this index does not supply any of them. Background revalidation preserves unsaved native editor input while the actual last validated catalog is still within its 60-second lifetime. Catalog requests have a 10-second deadline; timed-out flights are aborted and retired so later completions cannot restore permissions or prevent recovery. Failed reads and expiry revoke access, including on visible-tab resume during a stalled refresh; static permissions never replace missing catalog evidence.

Configuration ready is shown as Configured for launch, using the binary/Mail prerequisites shared with launch planning. Configuration blocked and unknown results include the available reasons. Negative legacy Mail flags cannot distinguish confirmed absence from failed probes, so their check remains unknown even when lack of positive configuration evidence blocks launch. Credential readiness remains unknown because no account/model check is performed. Generic provider cards have unknown session readiness; only a separately scoped API read with verified team/slot/member/session/pane evidence can establish a binding.

Local observation is shared across cards by one snapshot worker per API process, cached for 60 seconds. Requests wait at most two seconds and can show pending checks. A 90-second observation deadline initiates cleanup of the trusted observer-owned process group, with descendant reaping awaited before completion or refresh. The disposable Linux cleanup supervisor does not enable subreaping in the API process. Unavailable cleanup support or failed probes yields unknown readiness; this is not hostile-process containment or a precise OS-reap wallclock guarantee. Existing local version/runtime/MCP-inventory checks remain non-billable; no model calls, credential refreshes or disposable production sessions are used. Observations do not establish credential access, enforced execution isolation, milestone acceptance, pilot disposition or delivery reliability.

Codex has no native Backup/Usage/Context/transcript adapter here; export and diagnostics API support is separate from browser-page access. See restore/usage limits in Multi-Provider and Codex CLI. See Teams for reviewed launch/reuse and Live sessions for standalone work. Existing Pi opt-in/runtime/exact-resume requirements remain; this index changes neither integration nor sandboxing.

Muse Code

Muse Code is Meta's CLI (muse). Albiex Synth City runs it as a team member with the provider muse-cli, for example with the model muse-wonder-1.0.

• Subscription: a Muse subscription works only inside Muse Code. Synth City therefore launches Muse Code itself; it does not run the Muse models in another harness.
• Launch: muse --trust-workspace --model <model> [--reasoning-effort <tier>] [--yolo] [<prompt>]. Skip permissions maps to --yolo. Muse Code cannot be given a session id, so Synth City discovers it from the SessionStart hook or from the session lock that the process holds, saves it on the slot, and relaunches with muse resume <session id>.
• Agent Mail: Set up on the Muse Code page writes the user-wide settings file ~/.config/muse/settings.json (or $MUSE_CONFIG_DIR/settings.json). It adds the albiex-synth-city-mail MCP server and the SessionStart and UserPromptSubmit hooks, and keeps every other setting. Remove deletes only Synth City’s entries. Synth City refuses to change a file that it cannot read as settings.
• Questions: a hook cannot block Muse Code's question tool. Synth City reads the session's event log, shows a question as waiting for input, and notifies the bound Supervisor. Team charters should tell Muse members to write to the Supervisor instead of asking.
• Updates: the muse launcher updates Muse Code by itself. Each observation records the session's Muse Code version and model, so a change during a campaign is visible. Synth City does not pin the version.