The Agent Client Protocol registry (launched January 28, 2026 by JetBrains and Zed Industries) is a curated directory of AI coding agents that install natively into both IDEs without per-editor configuration. (Zed Blog, JetBrains AI Blog) As of April 20, 2026 it held more than 40 registered agents; by late June 2026 that count had passed 50, including several competing IDEs and frontier-lab CLIs. (GitHub) If you have been maintaining separate Claude Code, Codex, or Gemini integrations for each editor, there is now a single registration path that covers both, but migration has nuance worth understanding before you commit.
What ACP Actually Is (and What It Isn’t)
The Agent Client Protocol (ACP) is an IDE-to-agent integration layer: it defines how a coding agent communicates with a host IDE, analogous to how the Language Server Protocol (LSP) defines how a language server communicates with an editor. Just as LSP let language server authors write once and reach every LSP-compatible editor, ACP lets agent authors register once and appear natively in every ACP-compatible IDE.
ACP did not begin as a JetBrains and Zed joint venture. Zed Industries created and open-sourced the protocol in August 2025, well before the registry existed, and built it on JSON-RPC 2.0 messages exchanged over a subprocess’s stdin and stdout. [Updated June 2026] The host IDE launches the agent as a child process and talks to it over those pipes; there is no network listener and no long-running daemon. That design keeps the trust boundary local and the wire format cheap to implement, which is why official SDKs now exist for Kotlin, Java, Python, Rust, and TypeScript. (agentclientprotocol/agent-client-protocol) The schema is versioned and still moving: the stable protocol is version 1, with schema releases landing as recently as June 2026.
That analogy matters because “ACP” is ambiguous in the wild. IBM’s BeeAI project defines an entirely separate “Agent Communication Protocol” (also abbreviated ACP) that handles agent-to-agent messaging, not IDE integration. The two protocols are unrelated. Generic coverage conflates them regularly; anything you read about IBM BeeAI’s ACP is describing a different specification.
ACP is also distinct from MCP (Model Context Protocol), Anthropic’s tool-use and context-injection layer. MCP connects agents to external data sources and tools; ACP connects agents to IDEs. They operate at different layers and are not substitutes.
The divide is practical, not academic. The two protocols have acquired different backers, and the alignment is visible in who ships what. Microsoft standardized VS Code’s agent mode on MCP rather than ACP, and an open tracking issue for native ACP support has sat without a commitment from the VS Code team. [Updated June 2026] Anthropic stewards MCP; Zed and JetBrains drive ACP. An agent that wants to reach both the tool layer and the editor layer ends up implementing both specs: MCP to consume context and call tools, ACP to render its UI inside the editor. They stack. For developers tracking the broader move toward cross-tool agent standards, ACP is the editor-side counterpart to efforts like GitHub’s gh skill Agent Skills spec, which targets portable agent capabilities rather than editor wiring.
The Registry in Practice: How Agents Get Listed and How You Install Them
Distribution runs through a CDN at cdn.agentclientprotocol.com. Agent versions auto-update hourly via a cron job that polls npm, PyPI, and GitHub releases. (GitHub) From an end-user perspective, installed agents stay current without manual intervention.
Registering a new agent requires forking github.com/agentclientprotocol/registry, adding a directory containing an agent.json manifest and an optional icon.svg, then opening a pull request. (agentclientprotocol.com) CI validates schema compliance, slug uniqueness, icon format, URL accessibility, and binary OS coverage before merge. The submission process is deliberately conservative: the result is a curated list rather than an open package registry.
In both JetBrains and Zed, installation happens through the IDE’s agent picker rather than a marketplace. In Zed, agents auto-install on first use and authenticate via /login in a new thread. (Zed Documentation)
Supported Agents and Version Requirements
Zed
Zed requires version 0.202.7 or later. Claude Agent installs as @zed-industries/claude-acp; Codex installs as codex-acp (version 0.208+). Both auto-install on first use and authenticate via /login. (Zed Documentation)
JetBrains
JetBrains requires IDE version 2025.3.2 or later, plus AI Assistant plugin version 253.30387.147 or later. (JetBrains AI Blog) No JetBrains AI subscription is required. Authentication is handled by each agent provider’s own service.
As of March 2026, Cursor joined the registry and is available inside JetBrains IDEs through the agent picker, combining Cursor’s agentic workflows with JetBrains code intelligence. (JetBrains AI Blog) No JetBrains subscription is required for Cursor either. (JetBrains AI Blog) The Cursor addition is notable because Cursor is itself a competing IDE: its decision to join as an agent rather than a host signals that ACP has reached an adoption threshold where participation makes sense even for parties with competing interests.
Who Joined Since Launch
A registry is worth only as much as what is in it, and the list has grown well past the 40 entries it held in April. By late June 2026 it carried more than 50, and the names matter more than the count. Anthropic’s Claude Code, OpenAI’s Codex CLI, GitHub Copilot CLI, and Google’s Gemini CLI were early entries. The wave since then pulled in agents from across the competitive map: AWS shipped Kiro as an ACP agent you launch with kiro-cli acp, and Block’s Goose, Sourcegraph’s Amp, Cognition’s Devin, Factory’s Droid, and Cline all appear in the registry, alongside frontier-lab CLIs for GLM, Kimi, and Qwen. (Kiro Docs, GitHub) JetBrains also registered its own agent, Junie, so the company that co-launched the registry now distributes its first-party agent through the same neutral directory as its competitors.
LangChain registered deepagents, extending ACP reach to agents built on a framework rather than shipped as a standalone CLI. The pattern across all of these repeats the one Cursor set in March: vendors with their own editors or their own agent runtimes are choosing to meet developers inside whatever IDE the developer already runs, instead of fighting to be that IDE. That is the LSP outcome. The protocol won there because implementing it cost less than maintaining bespoke integrations per editor, and the same arithmetic is now playing out for agents.
One registry entry is already a moving target. Google sunset the standalone Gemini CLI on June 18, 2026, pushing users toward its Antigravity CLI. A registry listing is only as stable as the upstream tool it wraps, and the hourly auto-update cron will track an upstream rename or breakage whether or not your workflow is ready for it.
Migration Path: From Per-Editor Integrations to ACP
The coexistence window is currently open. If you have an agent installed through both a legacy per-editor extension and the ACP registry, the registry version takes precedence. (Zed Blog) Old Agent Extensions will eventually be deprecated, but no hard deadline has been announced as of 2026-04-20.
This means the practical migration path is non-disruptive: install the registry version alongside your existing integration, verify it behaves as expected, and then remove the legacy extension at your own pace. You are not forced to cut over immediately.
Docker’s Contribution: cagent and YAML-Defined Agents
Docker’s cagent is an open-source, YAML-based agent builder that ships with ACP support. It is bundled in Docker Desktop 4.49.0 and later. (Docker Blog) An agent defined as a YAML file runs inside any ACP-compatible IDE with a single command:
cagent acp <file>.yamlDocker’s role here is ecosystem contribution: cagent is an ACP-compatible tool, not a co-authorship of the protocol itself. The protocol was created by Zed Industries and later carried forward jointly with JetBrains, which co-launched the registry; Docker joined as a participant. [Updated June 2026]
Known Limitations
Two gaps are worth planning around before committing to ACP as your primary integration layer:
No thread history resume. ACP sessions do not persist conversation history between IDE sessions. Each new thread starts fresh. If your workflow depends on resuming long-running context across sessions, native integrations (where available) may still handle this better.
No past-message editing. You cannot edit a previous message in an ACP agent thread. This is a limitation relative to some native integrations and chat interfaces.
Local subprocess only. ACP today runs the agent as a local child process over stdin and stdout. Remote transports, which would let an editor connect to an agent running on another machine, are on the roadmap but not shipped as of June 2026. Teams hoping to point a thin editor client at a hosted agent backend will not find that path yet. (agentclientprotocol/agent-client-protocol)
None of these is a blocker for most coding workflows, but teams that have built workflows around session continuity or remote execution should evaluate the gap before migrating.
Should You Standardize on ACP Today?
The registry is stable enough to adopt. The CDN distribution, hourly auto-updates, and PR-based registration process are all production-grade infrastructure choices. Cursor’s March 2026 addition (a competing IDE joining as an agent) is the clearest signal that ACP has reached a point where major actors are treating it as a durable standard rather than an experiment.
The case for waiting is thin. The coexistence window means migration carries minimal risk today. The known limitations (no thread resume, no message editing, no remote transport) are real but narrow. For teams running separate Claude, Codex, and Gemini configurations per editor, consolidating to ACP reduces maintenance surface without losing capability that matters for the majority of coding workflows. If you are still weighing Claude Code against Cursor and Copilot on cost, ACP shifts the framing: the choice of agent stops being locked to the choice of editor.
The one genuine caveat: if your team relies on VS Code as a primary editor, ACP coverage there is still community-driven rather than officially supported. Multi-editor teams spanning VS Code and JetBrains or Zed should factor that asymmetry into their timeline.
FAQ
Is ACP the same as MCP? No. MCP (Model Context Protocol) is a tool-use and context-injection layer that connects agents to external data sources and services. ACP (Agent Client Protocol) is an IDE-integration layer that connects agents to editors. They operate at different levels of the stack and are complementary, not redundant.
Do I need a JetBrains subscription to use registry agents in a JetBrains IDE? No. Access to the ACP registry does not require a JetBrains AI subscription. Each agent authenticates through its own provider’s service. (JetBrains AI Blog, JetBrains AI Blog)
How do I register my own agent? Fork github.com/agentclientprotocol/registry, add a directory with an agent.json manifest and optional icon.svg, and open a pull request. CI validates schema compliance, slug uniqueness, icon format, URL accessibility, and binary OS coverage before the PR is merged. (agentclientprotocol.com)
What happens to my existing agent extensions during migration? Registry-installed and extension-installed versions of the same agent coexist during the transition window. When both are present, the registry version takes precedence. Legacy Agent Extensions are planned for eventual deprecation, though no firm timeline has been set as of 2026-04-20. (Zed Blog)
