Harnesses
Overview of Coven harnesses, built-in adapters, provider-auth boundaries, project-root rules, and external adapter manifests.
2 min read
A harness is an external coding-agent CLI that Coven can launch inside a project root. Coven owns the PTY, session record, event log, attach/replay flow, and local API boundary. The harness owns the conversation, provider authentication, and tool execution inside its own process.
The built-in harness ids are codex, claude, coven-code, and copilot. Trusted adapter recipes (grok, hermes) and local manifests can register more — see Custom adapters.
Built-in harnesses
| Harness | Harness id | Executable | First command |
|---|---|---|---|
| Codex | codex | codex | coven run codex "fix the failing tests" |
| Claude Code | claude | claude | coven run claude "polish this UI" |
| Coven Code | coven-code | coven-code | coven run coven-code "explain this repo" |
| Copilot CLI | copilot | copilot | coven run copilot "summarize this repo" |
Runtime boundary
The daemon validates the harness id, project root, working directory, session id, live-session state, and control actions. It does not read provider credentials and does not become the provider client.
Read next
- What is a harness? for the concept boundary.
- Install harness CLIs for harness setup.
- Provider auth boundary before auditing credentials.
- Project roots and working directories before debugging launch rejects.
- Codex, Claude Code, Coven Code, and Copilot CLI for adapter-specific behavior.
- Custom adapters for external adapter manifests and the trusted grok/hermes recipes.
- Troubleshooting when
coven doctororcoven runfails.
Related
Last updated on