One ACP client for the agent you already use

What ACP is

The Agent Client Protocol is an open protocol between a coding agent and the program that drives it: the client starts the agent as a process, speaks JSON-RPC to it over stdio, sends prompts, and receives the agent's messages, tool calls and permission requests. An editor is one kind of client. Warding is another: a client that runs as a service, so the agent keeps going when no editor is open, and the permission requests the agent sends can be answered from the dashboard or a chat app.

The eleven runtimes it can dock

Each runtime is one entry in the registry: the command that starts it, and what it needs installed. A check appears only where a dated row exists on the verification log. Today that is Claude Code, for chat. Every other cell is registered and unverified, and says so.

No Gemini CLI yet. The full matrix, capability by capability, is on the registry.

Adapters, named

• Claude Code is reached through claude-agent-acp, an adapter published by the ACP project, not by Anthropic. If it is not installed, it is fetched with npx on first run, so the first start needs Node and a network connection. The Claude Code session runs under your own login; for shared or production automation, use an API key.
• Codex and Pi are reached the same way, through their ACP adapters fetched with npx. Codex still needs the codex CLI installed and logged in.
• Cursor, Kimi, Goose, Grok, OpenCode, Droid speak ACP from their own CLI, started with the flag in the table. OpenCode signs in to OpenRouter and other providers with its own login.
• The legacy adapter is optional and last in the order. With the harness set to auto, the first installed runtime in the table's order is docked.

What Warding adds around the agent

• Schedules

  Cron jobs and a template gallery, created from the dashboard or the CLI. Schedule

• Chat channels

  10 apps: 5 with approve buttons, 1 with typed approvals, 4 chat-only. Channels

• A gate in front of tool calls

  Tool calls go through Warding's own gate: built-in deny rules and POLICY ∩ PROFILE are checked there, and a gated call waits for your answer. Security

• A policy it cannot open

  The policy files sit on the keystone deny list, so the agent can neither read nor write them.

• A sandbox and an audit log

  An OS sandbox where the host supports one, and a hash-chained log of what was allowed and refused.

• Memory and Agent Worlds

  Memory and lessons across sessions, and a pixel sprite for each live one. Agent Worlds

One harness for chat, and what that costs

• Chat runs the one harness you choose. Every chat session, channel and scheduled job uses it. Switching is one setting (agent.acp_backend), and your schedules, memory and channels stay.
• A spawned subagent can run elsewhere. The harness router (warding route) sends a spawned subagent to another installed harness: flat-rate plan quota before metered spend, the kind of task, and a cooldown after a usage limit or a failed login. It picks a harness and never forwards provider traffic. Registered · unverified.
• The agent's own tools depend on the harness integration. Availability depends on permission mode and session identity. Agent-managed jobs, subagents and mid-turn questions remain unverified. Manage schedules from the dashboard or CLI. Being extended
• Mostly unverified. The runtimes are registered; which features have been run on each is on the verification log, with dates.