Harnesses

Harnesses provides operation details, configuration and session entry points even when no repositories are watched. All five 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 and Pi 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.