Harnesses
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 — 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:
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.
