Install Harness CLIs
How to install Codex, Claude Code, Copilot CLI, and the Coven Code engine for Coven, how detection works, and how to recover from PATH or auth setup problems.
1 min read
Coven manages one harness itself — the bundled Coven Code engine — and detects every other harness CLI on PATH. External harnesses are installed and authenticated through their own provider's tooling.
Built-in harnesses
| Harness id | Executable | Install command | Provider login |
|---|---|---|---|
codex | codex | npm install -g @openai/codex | codex login |
claude | claude | npm install -g @anthropic-ai/claude-code | claude doctor |
copilot | copilot | npm install -g @github/copilot | copilot login |
coven-code | coven-code | coven engine install | Inside Coven Code (/connect) |
Beyond these, trusted adapter recipes (grok, hermes) and your own manifests can register external harnesses — see Custom adapters.
After installing, run:
coven doctorcoven doctor reports whether the executable is available. It does not read provider credentials; the login command remains provider-owned.
Detection flow
Only registered harness ids are accepted: the built-ins plus any adapter manifests configured on the machine running Coven. A client cannot send an arbitrary executable path through the daemon API.
PATH and daemon environment
If you install a harness after the daemon is already running, restart the daemon so the process environment is fresh:
coven daemon restart
coven doctorIf coven doctor still reports a missing harness, check duplicate or unexpected binaries:
which -a codex
which -a claude
which -a copilotThe bundled engine is not a PATH install: use coven engine status and coven engine which instead — see Coven Code harness.
First launch
coven run codex "describe this project"
coven run claude "review this project for risky defaults"
coven run copilot "summarize open TODOs"Use Provider auth boundary if a harness launches but exits with a provider login error.
Last updated on