---
title: "Harnesses"
url: "https://control.actana.ai/docs/core/harnesses"
description: "The vendor CLIs a Core can run, the compatibility table, and how a Harness gets installed under the Core's user."
updated: 2026-09-01T09:03:15+00:00
---

A **Harness** is the vendor coding CLI a session drives. It is a program Actana runs, not a part of Actana: the Core spawns it into a PTY on the machine that has your repo, and the Panel never sees more than an id and an availability status.

## Supported

The rows track the shared harness registry one-for-one, as of the current release:

| Harness | Command | Status | Auto-approve flag |
| --- | --- | --- | --- |
| Claude Code | `claude` | Supported | `--dangerously-skip-permissions` |
| Codex | `codex` | Supported | `--yolo` |
| Cursor CLI | `cursor-agent` | Supported | `--force` |
| OpenCode | `opencode` | Supported | none offered |
| Hermes | — | Coming soon | — |
| Pi | — | Coming soon | — |

The family is **open** by design: a Harness is one registry entry plus a launcher, and nothing in the Panel or the core-link is specific to any of the four supported today. Using one that is not here? [Open an issue](https://github.com/actana/control/issues/new) — that is how a row gets added. Coming-soon entries appear in the Panel as themselves, not installable yet.

From the CLI, `actana session start` accepts `--harness` with those ids (`claude-code`, `codex`, `cursor-cli`, `opencode`) and `--dangerously-skip-permissions` when you want the Core to pass the vendor's auto-approve flag.

## Installing a Harness

Each Core needs the CLIs it will spawn, installed under **that Core's own user**. A CLI on your laptop does not count for a Core on a workstation. The Core probes its PATH at startup, on a tick, and after an install, then publishes availability; the Panel reads that snapshot and never inspects a remote PATH.

On a terminal, `actana setup` offers each missing Harness in turn and installs the ones you accept with the vendor's own installer — so that Harness's updater and login still work afterwards. Non-interactive: `--with-<harness>` for specific ids, `--yes` for every missing one, `--no-harnesses` for none. With no terminal and none of those flags, setup installs nothing and asks nothing.

Declining is not permanent:

```bash
actana harnesses install opencode
```

The id is the Harness name or its command (`claude-code` and `claude` both work). A vendor installer that fails is reported with the vendor's docs URL and never fails your Core install. After an install the Core re-probes, so a paired Panel sees the new Harness without a daemon restart.

From another machine, ask the same Core over the link — `actana harness install <id>` — which waits for the Core's verdict (available on PATH), not the vendor installer's exit code. From the Panel, a missing Harness at session start can be installed the same way: acknowledged immediately, outcome on the event log.

## What is never touched

The Panel never writes into `~/.claude`, `~/.codex`, `~/.cursor`, or any other Harness skill directory. The one exception is the two Actana skills, and those are written by the `actana` CLI on the machine the Harness runs on — not by the Panel. See [CLI Skills](/docs/cli/skills).

## See also

- [Operating a Core](/docs/core/operating)
- [Sessions](/docs/panel/sessions)
- [CLI Commands](/docs/cli/commands)
- [Concepts](/docs/introduction/concepts)