Agent Client Protocol: How one standard lets any coding agent run in any editor

The Agent Client Protocol (ACP) is an open standard for how a code editor talks to an AI coding agent. It defines a shared set of messages, so one agent can work inside many editors without a separate plugin for each. Think of it as a common plug shape for editors and agents.

One agent, many editors, and the plugin pile it creates

Picture a team that wants to use an AI coding agent. Today the agent often ships as a terminal tool. It works, but the developer keeps switching between the terminal and the editor to see changes and approve steps.

The alternative is a plugin inside the editor. That means the agent maker writes one plugin for each editor, and each editor maker writes one integration for each agent. With 5 editors and 10 agents, that is up to 50 custom connections.

ACP replaces that grid with a single contract. An editor that speaks ACP can host any agent that speaks ACP. The protocol documentation compares the idea to the Language Server Protocol, which did the same job for language tools such as code completion and error checking.

Two roles, one conversation in plain messages

The protocol has two sides. The client is the editor, which the person is looking at. The agent is the program that plans and carries out coding work. The two exchange messages in JSON-RPC 2.0, a simple request-and-response format. Local agents run as a sub-process of the editor and talk over standard input and output, according to the documentation. Remote agents over HTTP or WebSocket are described as still a work in progress.

A typical session, as laid out in the protocol overview, goes like this:

1. The editor calls initialize. Both sides agree on a version and list what they support.
2. The editor calls session/new to open a session. If the agent supports it, session/load can resume an older one.
3. The user types a request, and the editor sends it with session/prompt.
4. While working, the agent streams session/update notifications. These carry text, tool calls, plans and progress.
5. When the agent wants to do something that needs a yes, it calls session/request_permission. The editor shows the question and returns the answer.
6. The turn ends when the agent replies to the prompt with a stop reason. The editor can interrupt earlier with session/cancel.

The permission step matters. The agent asks, and the editor, which the person controls, decides.

Why the editor keeps the files and the terminal

In ACP the editor holds the resources the agent needs. The agent can ask the editor to read or write a file with fs/read_text_file and fs/write_text_file. It can also run commands through terminal methods such as terminal/create and terminal/output.

These features are optional. Each is gated by a capability that the editor declares at startup. An agent has to check what the editor offers and cope without it. That keeps simple editors able to take part, while richer ones can expose more.

ACP also borrows from the Model Context Protocol (MCP), the standard for connecting models to tools and data. The documentation says ACP reuses MCP’s JSON formats where possible and adds its own types for coding-specific needs such as showing diffs. The two solve different problems. MCP connects an agent to tools. ACP connects an agent to the editor the person is using.

From Zed and Gemini CLI to a wider industry

Zed, the editor maker, created ACP. Its ACP page points to an August 27, 2025 post introducing it, with Google’s Gemini CLI as the first integration. The Register reported on October 7, 2025 that the work grew out of a Google and Zed collaboration on IDE integration, and that JetBrains would support ACP and work with Zed on it. JetBrains’ stated benefit, as the report relays it, is no vendor lock-in: developers can use the assistant they prefer in any ACP-supporting IDE.

The project is open source under the Apache license. Zed’s page lists editors including Zed, JetBrains IDEs, Visual Studio Code, Neovim and Emacs. It lists agents including Claude Agent, Codex CLI, Gemini CLI, Cursor, GitHub Copilot, Goose and OpenCode. These are Zed’s own lists, so the exact level of support varies by product and release stage.

Where ACP shows up in the Copilot story

JetBrains Air is a JetBrains tool for running several agent sessions side by side. Our report on GitHub’s weekly Copilot roundup covers Copilot arriving there, with tasks that run locally or in the cloud on an existing Copilot subscription. The Air plugin is labeled alpha on the JetBrains Marketplace.

JetBrains’ July 2026 post on Air, as summarized in search results, says Air supports GitHub Copilot, OpenCode, Pi, Cline and other ACP-compatible agents. It also says Air connects to the GitHub Copilot command line tool through that tool’s ACP server mode. In plain terms, Air does not need a Copilot-specific engine. It speaks the standard, and Copilot answers in kind.

That is the practical payoff. A company can keep its managed Copilot access and still choose the editor or agent hub its developers like.

What a shared protocol does not solve

A standard connects the pieces. It does not make them equal. Several limits are worth knowing:

• Remote agents are unfinished. The documentation says full remote support is still in progress, so cloud-hosted agents rely on vendor-specific layers for now.
• Features depend on the editor. Capabilities are optional, so an agent may behave differently in two editors that both claim ACP support.
• Business rules stay outside the protocol. Billing, admin limits and usage analytics are decided by each product. Our earlier coverage noted that Air’s governance tools reportedly do not cover Copilot usage.
• Lock-in has other forms. The Register notes that ACP alone will not remove the pull of Visual Studio Code’s extension ecosystem.
• Privacy depends on the agent. Zed says nothing touches its servers when you use third-party agents. The agent itself may still send code to its own provider, so the model vendor’s terms still apply.

What to watch as the standard matures

Three things will show whether ACP becomes the default plug. The first is remote support, since more agents now run in the cloud rather than on a laptop. The second is how consistently big editors implement the optional capabilities. The third is whether more commercial agents expose an ACP mode directly, as the Copilot command line tool reportedly does, rather than only through their own plugins.

The community now governs the specification in public, so changes arrive as open proposals. For developers, the simplest test is a practical one: can you switch the editor or the agent without rebuilding your workflow? ACP is an attempt to make the answer yes.