Distribute your harness

A harness is distributable the moment its repository or package contains a valid one.json. There is no submission process or server-side registration; installation is a local, user-consented action through the CLI, Desktop, or a one://harness/install?source=... deep link. Sigstore verification is not in the public install flow yet.

Install sources

A manifest install validates the manifest, checks requirements, asks for consent, runs doctor, and confirms an ACP initialize and session setup before adding the harness to the machine catalog. An acp: install generates a manifest for the command you entered and runs the same checks. Neither launches the command through a shell.

One Horizon seeds curated manifests into ~/.one/runtimes.d. A matching OpenCode manifest appears as Curated and enables after its vendor authentication check and ACP handshake pass.

The installed harness appears in one agent create and Desktop's Add-agent picker. npx @onehorizon/cli harness install ./ uses the same implementation without a global CLI install.

Desktop accepts a local source through Agents → Add agent → Add harness, which opens a short explainer and a file picker for one.json; a one://harness/install?source=... deep link opens the same picker pre-filled.

After you choose a harness, Desktop shows a Review step with the publisher, exact launch command, and what it can access, whether the harness still needs consent or is already enabled.

Zero-touch discovery

If your product has its own installer, skip even the install command: write your manifest into the drop-in directory.

~/.one/runtimes.d/conductor.json        # macOS/Linux (per-user)%USERPROFILE%\.one\runtimes.d\conductor.json # Windows

Desktop and the CLI scan this directory. The next time the user opens Add agent, your harness appears as Detected on this machine, and enabling it requires the user's consent.

Bundling inside your own product

If your app ships its own installer, bundle the integration:

1. Ship one.json inside your app bundle.
2. After your own install completes, run one harness install <path-to-manifest-dir>, or hand off to Desktop with a one://harness/install?source=<path-to-manifest-dir> deep link so the user finishes consent in the picker.
3. Optionally run one agent create --harness conductor to take the user straight to creating an agent. Pass --permission-level and --task-mode to preset those choices. The user still signs in through the browser if they are not signed in yet.

Versioning and updates

• The catalog records the manifest version at install time; it is shown on the agent details page and in one harness list.
• one harness update [name] re-reads an installed local source and records new consent before the next turn. Desktop does not resolve harness updates yet.
• Updates are per machine, so the same harness can run different versions on different machines.
• Bump the major version for breaking changes in your agent's behavior, since workflow authors depend on what your harness does.

Trust and safety

A harness process runs with the user's OS permissions, the same trust level as any software they install, including the built-in agent binaries. One Horizon presents what will run at the moment of consent; it does not gatekeep what a user runs on their own machine.

• Detected entries from runtimes.d never get a badge. The consent screen shows the publisher, version, terms links, and the exact command that will run, and nothing executes before the user enables it.
• A harness shows Curated only while its file matches the entry One Horizon shipped. A copied, renamed, or edited manifest is treated as detected.
• Enabling snapshots the manifest digest and resolved launch argv. Desktop displays the argv as JSON so spaces cannot hide argument boundaries, and rejects control or bidirectional formatting characters. If the manifest or launch digest changes later, the harness is paused and the consent screen returns.
• Agents run unattended, so ACP session/request_permission is answered by host policy. On the Review step, When the agent asks for extra permissions lets the user choose Deny requests (recommended) or Allow one-time requests. Built-in Agent access (Read-only / Workspace access / Full access) is a separate trust boundary for Codex, Claude, and Cursor.
• A detected manifest whose name or displayName collides with a built-in harness or one already installed on the machine is not shown.
• One Horizon can block a harness by ID, name, manifest, launch command, or publisher. A blocked harness cannot be scheduled or claim work, but workflows that reference it stay intact.
• Publisher verification is not in the public install flow yet, so unsigned local harnesses stay unverified.
• Software able to write to runtimes.d is already running code as the user; the folder grants visibility in the picker, not capability.

A note on names

Catalog names are machine-local, so there is no global name race. displayName is what users see; make it match your brand. Keep name stable: changing it orphans existing agents' harness references and forces users to re-create agents.