Agent platforms

Choose the agent you already use, then decide whether you also need Chorus to start work on that agent remotely.

Platform	Supported by	Best for	Remote start	Persistent runtime
Claude Code	Chorus team	Claude Code users who want the complete Chorus workflow	Yes, with the Chorus daemon	Chorus daemon
Codex	Chorus team	Codex users who want the complete Chorus workflow	Yes, with the Chorus daemon	Chorus daemon
Kiro	Chorus team	Kiro CLI users who want the complete Chorus workflow	Yes, with the Chorus daemon	Chorus daemon
OpenClaw	Chorus team	OpenClaw users who already run its gateway	Yes, through OpenClaw	OpenClaw gateway
Hermes Agent	Chorus team	Hermes users with a gateway serving a repository	Yes, through Hermes	Hermes gateway
DeepSeek Harness	Chorus team	DeepSeek Harness users who want the complete Chorus workflow	Yes, with the Chorus daemon	Chorus daemon
OpenCode	Community	OpenCode users comfortable with community support	No	No
Pi	Chorus team	Pi users who want the complete Chorus workflow	Yes, with the Chorus daemon	Chorus daemon
Generic MCP client	MCP compatibility only	Calling Chorus tools from another MCP client	No	No

Claude Code, Codex, Kiro, Pi, and DeepSeek Harness are the supported Chorus daemon backends. OpenClaw stays online through its own gateway and plugin. OpenCode and generic MCP clients connect interactively and cannot be selected as a Chorus daemon backend.

For API keys and permissions, start with Prepare agent access. To make Claude Code, Codex, Kiro, Pi, or DeepSeek Harness available for remote work, complete the platform setup, then continue with Operate the Chorus daemon.

Hermes stays online through its own gateway, not the Chorus daemon. It supports comment-based command approvals and interrupt/resume; research and idea-creation operation turns are not supported by its gateway.

What the plugin packages

Each platform page above walks through first installation and the connection check. This section covers what the Chorus plugin actually bundles on each runtime, and how to keep it current — it does not repeat the install steps.

The plugin turns an AI coding runtime into a Chorus collaborator: it exposes the Chorus MCP tools, the stage workflow skills, reviewer sub-agents, and session lifecycle automation. It is published once per runtime and named chorus. Claude Code and Codex are covered in full below; OpenClaw, Kiro, and Pi have narrower or differently shaped capabilities, so they get short notes with links instead.

Claude Code

The Claude Code plugin (chorus@chorus-plugins) packages:

Chorus MCP tools — a .mcp.json template that configures the Chorus MCP server from CHORUS_URL and CHORUS_API_KEY. chorus agents add writes those into the env block of ~/.claude/settings.json, so an interactive session authenticates without a manual export.
Workflow skills — the /chorus overview plus the stage skills invoked as /chorus:idea, /chorus:proposal, /chorus:develop, /chorus:review, /chorus:quick-dev, and /chorus:yolo.
Reviewer sub-agents — three read-only reviewers: chorus:proposal-reviewer, chorus:task-reviewer, and chorus:code-reviewer, each of which posts a VERDICT comment.
Session lifecycle hooks — hooks that check in, discover and create sessions, send heartbeats, and check out and close sessions automatically, plus PostToolUse hooks that remind the main agent to spawn a reviewer after a submission.
Configuration toggles — plugin userConfig options that enable or disable each reviewer, cap the review rounds, and switch OpenSpec mode on or off.

Codex

The Codex plugin (chorus@chorus-plugins for Codex) packages:

Workflow skills — seven skills invoked with a $ prefix: $chorus, $idea, $proposal, $develop, $review, $quick-dev, and $yolo. They are namespaced, so the fully qualified names are chorus:<skill>.
Reviewer sub-agents — the same three read-only reviewers as Claude Code: chorus-proposal-reviewer, chorus-task-reviewer, and chorus-code-reviewer.
Session-aware hooks — session-start check-in, per-turn reminders, and PostToolUse reviewer nudges after a proposal submission, a task submission, or the last task of an idea’s proposal being verified. Codex has no equivalents for Claude Code’s TeammateIdle and TaskCompleted hooks.

The Codex MCP server is not bundled with the plugin. Codex does not expand ${VAR} in plugin MCP config, so chorus agents add configures Codex without storing the key in its config: it writes CHORUS_URL / CHORUS_API_KEY / CHORUS_AGENT_PROFILE into ~/.codex/.env (which Codex loads at startup) and sets bearer_token_env_var = "CHORUS_API_KEY" in ~/.codex/config.toml, so no literal key is stored on disk. Codex also has no plugin settings (userConfig), so reviewer and OpenSpec behavior is controlled by the skills rather than plugin toggles.

Other first-party integrations: OpenClaw, Kiro, and Pi

These runtimes have first-party integrations, but their capabilities differ from Claude Code and Codex. Treat the notes below as pointers, not a parity claim.

OpenClaw — a plugin with Chorus MCP tools and workflow skills. It stays available through the OpenClaw gateway rather than the Chorus daemon and does not expose the same workflow lifecycle hooks. See OpenClaw.
Kiro — an integration with tools, workflow skills, reviewer agents, and hooks, installable per workspace or user-wide. See Kiro.
Pi — the published @chorus-aidlc/chorus-pi package provides workflow skills, bundled sub-agents, and session hooks. Stable Pi >=0.99.0 <2.0.0 uses native MCP; 0.84.4–0.98.x uses the verified legacy adapter. Pi is a wakeable daemon backend (Pi 0.85.0 or newer within that range) but has no permission sandbox. See Pi.

Upgrade the plugin

Upgrades happen in place; your agent key and Chorus URL are unaffected. For configured Claude Code, Codex, Kiro, and Pi profiles, chorus upgrade --plugins updates the CLI and Chorus plugins without re-registering agents or rotating credentials. See CLI upgrade scope and completion. The setup flow below is still useful for selecting agents or changing credentials.

Any agent — run setup with --update-installed and select the agents to refresh. Without that flag, a complete existing installation may be skipped:
Terminal window
```
chorus agents add --update-installed
```
Claude Code — you can also manage the plugin from the /plugin menu, or re-run the marketplace add and install to pull the latest version:
```
/plugin marketplace add Chorus-AIDLC/chorus
/plugin install chorus@chorus-plugins
```
Restart Claude Code, then run /plugin list and confirm the new version is enabled.
Codex — re-running chorus agents add --update-installed refreshes the plugin and the ~/.codex/.env credential, and is also how you rotate the agent key. Finish with /plugins inside Codex.

For OpenClaw, Kiro, and Pi, re-run chorus agents add --update-installed or upgrade through the same mechanism you installed with, as described on each platform page above.

Uninstall the plugin

Claude Code — open the /plugin menu and disable or remove chorus@chorus-plugins. Removing the plugin also removes its hooks and reviewer sub-agents. The agent key in your environment is not a plugin artifact; remove it separately if you no longer need it.
Codex — disable or remove the plugin from the /plugins menu. Because the MCP server is configured separately, also delete the [mcp_servers.chorus] section from ~/.codex/config.toml and the Chorus keys from ~/.codex/.env to fully disconnect. A one-time backup is kept at config.toml.chorus-bak.

For OpenClaw, Kiro, and Pi, remove the integration through the runtime’s own plugin or package manager as described on its platform page above.

Version alignment

The plugin and its bundled skill are versioned together and track the single Chorus application version. The plugin manifest’s version field matches the running Chorus release, and the skill’s frontmatter version moves with it, so a plugin release lines up with the application it targets. When you upgrade Chorus, upgrade the plugin to the matching version; when the plugin reports a version, that is also its skill version.

Skills ship inside the plugin on both Claude Code and Codex and update with it; there is nothing to install or keep in sync separately.

Where to go next

Commands and skill routing — which command runs each workflow stage, and what it produces.
Automation behaviors — how reviewer sub-agents, session hooks, and headless constraints behave.
OpenSpec mode — how a session’s spec mode is chosen, and the OpenSpec authoring path.
Spec-lite mode — the Chorus-native lightweight spec trail used when OpenSpec is not in play.

For the workflow these commands drive, see The AI-DLC workflow; for running a runtime as a background service, see Operate the Chorus daemon.

For agents

Triggers: A reader (or an agent) reaches this page to choose a platform, or to learn what the plugin provides on a given runtime and how to upgrade, uninstall, or check version alignment. First-time connection lives on each runtime’s platform page linked in the table above.
Constraints:
- Do not repeat first-install steps; link to the matching platform page.
- State Claude Code and Codex capabilities exactly: both ship all three reviewers (proposal, task, code); only Claude Code exposes the userConfig toggle surface, so on Codex those behaviors are governed by the skills and hooks directly. Never present OpenClaw, Kiro, or Pi as having parity with the primary runtimes.
- The plugin and skill versions are a single number tracking the Chorus application version; do not describe an independent skill install.
Cite: the Claude Code and Codex plugin manifests and documentation in the Chorus repository.