Harnesses
A harness is the coding agent that does the work. toryo drives one; it is not one. Three are supported: Claude Code, Codex and GitHub Copilot.
You bring your own, signed in under your own account. toryo licenses toryo and takes no margin on model usage, which is also why switching harness changes nothing about what you pay us.
They are not equivalent, and toryo does not pretend they are#
Every harness declares what it can and cannot do, feature by feature, and toryo asks that declaration rather than assuming. A step that needs something a harness lacks is refused where it was configured, not discovered halfway through a run.
The gaps worth knowing before you choose:
| Capability | Claude Code | Codex | Copilot |
|---|---|---|---|
| Enforcing a tool deny list | yes | emulated | emulated |
| MCP servers | yes | yes | yes |
| Streaming progress | yes | emulated | yes |
| Reporting usage | yes | emulated | yes |
| Estimating cost | yes | no | no |
| Structured JSON output | yes | no | no |
| Execution modes | yes | no | no |
| Subagents | yes | no | no |
| Context optimization | emulated | no | no |
| Cancelling a run | yes | yes | yes |
| Resuming a dead session | no | no | no |
Emulated means toryo delivers the outcome the harness does not offer natively, by doing the work itself. The result is the same; the mechanism is toryo's rather than the harness's.
Two rows deserve their own sentence. Nothing resumes: a failed step restarts from the beginning rather than picking up inside the session that died, on every harness. And cost estimation is Claude Code only, so the per-job cost figures you see in the queue are blank for work run on the other two.
The table above is the short version. toryo generates the precise matrix from the code itself, so if a run is refused for a capability reason the message names the feature and the harness rather than leaving you to guess.
Choosing which ones this machine offers#
Most people run one or two. Offering all three in every picker, and letting a job queue against a harness whose CLI was never installed, is worth turning off:
toryo worker settings set --provider-codex false
One switch per harness, all on by default. Board has the same switches on the Settings screen.
Two rules hold this together:
- At least one stays on. A write that would leave none is refused, as is one that turns off the harness your default names. A machine in either state accepts no work at all, and the failure would otherwise surface job by job rather than where you configured it.
- A job naming a disabled harness is refused when you queue it, with the flag that re-enables it named in the message. Not three steps into the run.
toryo sequence validate warns about the same thing earlier: a sequence whose
steps name a harness this machine has switched off draws a warning naming the
steps. It is a warning rather than a failure, because which harnesses a machine
offers is a property of the machine and the file may be perfectly good on a
colleague's.
Picking a harness per step#
A sequence step can name the harness it wants. code-task exposes this for each
of its five agent roles, so planning can run on one harness and implementation on
another. It is a providers object in the run input, keyed by role:
{
"brief": "...",
"workingDir": "/Users/you/dev/myrepo",
"branchName": "feat/thing",
"baseBranch": "main",
"maxImplementAttempts": 3,
"providers": {"plan": "claude", "implement": "codex"}
}
The five roles are plan, implement, selfReview, review and reflect.
Any role you leave out runs on Claude Code. Board's run form offers the same
choice as a set of pickers, so this is only the shape if you are launching from
a terminal with --input.
Your own sequences can do the same, and can go further: a step can decide its harness from the run's own input, so a field you fill in at launch picks it. See Writing your own sequences.
Outside a sequence, a job that names no harness uses this machine's default, and a default that names nothing resolves to the first harness you have left enabled.
Where the work runs#
Every agent session runs inside its own tmux session on your machine, whichever harness it is. That is what lets a long task keep going after you close the window, and lets you attach to a running one. Nothing is uploaded and no session runs in a cloud sandbox.
Harnesses are also MCP clients#
The same three programs are places toryo's own tools can be installed, which is a separate question from which one runs your jobs. A machine can drive work on Claude Code while also exposing toryo's tools inside Codex. See MCP.
Where things go wrong#
- A job is refused at the queue naming a harness. That harness is switched off on this machine. The message names the flag.
- Cost is blank on a job. It ran on Codex or Copilot, neither of which reports it.
- A capability you expected is missing. Check the table above before assuming a bug. Structured output, subagents and execution modes are Claude Code only.
- A run failed and restarting resumes nothing. Expected: no harness resumes.
Use
retry, which keeps the run's worktree, PR and history.
Full command surface: CLI & contract reference.