Coding agents
A runner does not write code itself. It drives a coding agent: an existing command-line tool that reads a task, edits files, runs commands, and reports what it did. The runner supplies the workspace, the boundary, the sign-in, and the task; the coding agent does the work inside all four.
Which tool a runner can drive is called its adapters. A runner detects them when it starts, lists them during pairing, and shows them in the fleet.
The four adapters
Section titled “The four adapters”| Adapter | Tool | Installed by the runner installer | Needs |
|---|---|---|---|
claude-code-cli | Anthropic’s Claude Code | Yes | An Anthropic credential |
openai-codex-cli | OpenAI’s Codex | No | The codex binary on PATH, and an OpenAI credential |
gemini-cli | Google’s Gemini CLI | No | The gemini binary on PATH, and a Google credential |
commandchain-agent-cli | The built-in agent | No | The commandchain-agent binary on PATH |
Claude Code is the one the installer sets up for you, using its own native build, so a fresh install has a working coding agent with no extra steps and no Node.
The others are opt-in. Open the runner with commandchain-runner and press i to install one, or run commandchain-runner agents install codex (or gemini). Each installs with the vendor’s own installer, and the runner offers it for work the next time it starts.
How a run picks one
Section titled “How a run picks one”The control plane chooses the adapter when it dispatches a run, and the runner uses the one it was told to use. A runner that does not have that adapter does not silently substitute another.
In practice that means:
- A runner with only
claude-code-clitakes coding runs targeted at Claude Code. This is the default after a fresh install. - A runner with several adapters can take any of them, and which one a given run uses is decided by your workspace’s model and routing policy rather than by the machine.
- A run dispatched for an adapter nobody has waits rather than running with the wrong tool. See troubleshooting.
Every adapter runs inside the same boundary
Section titled “Every adapter runs inside the same boundary”The sandbox is applied by the runner, uniformly, and does not depend on which tool is executing. All four are started through the same launcher, get the same synthetic home, and get the same environment allowlist. Each receives its own sign-in and no other one’s.
That is why adding a coding agent to a machine does not widen what an agent can reach: the tool changes, the boundary does not.
The runner’s own sign-in per tool
Section titled “The runner’s own sign-in per tool”Each adapter authenticates with its own provider, so the runner keeps its own sign-in per coding CLI, on this machine, separate from yours. Press s on the runner screen to see which ones are signed in, and to sign in to Claude Code, Codex or Gemini CLI, with your browser or an API key. Nothing is uploaded.
A run dispatched for a coding CLI the runner is not signed in to does not start on that runner. The task says no connected runner is signed in to the coding agent it needs. Open the runner on that machine with commandchain-runner and follow its prompt. Once a runner is signed in to that coding CLI, or managed runs are turned on for the workspace, the task picks itself back up and runs. There is no need to reassign it or move it by hand. See sign-in only or full setup.
Runs on CommandChain’s managed servers are different: they use a login you upload for managed runs. See managed runner credentials.
Next steps
Section titled “Next steps”- Sign-in only or full setup: sign the runner in to each tool.
- Knowledge in runs: what a coding agent can look up mid-run.
- MCP servers: the outside tools a coding run can call.
- Workspaces and git: the checkout the agent works in.