The Agent Client Protocol is a standard way for a code editor to talk to a coding agent. Zed started it in 2025. JetBrains joined in October 2025 to bring it to IntelliJ and the rest. If an agent speaks ACP, any ACP editor can drive it. If an editor speaks ACP, it gets every ACP agent for free.
We built GetPullRequest (GPR) on it. Slightly odd, because GPR isn't an editor. It's a phone app that runs coding agents on your own machine. Protocol first, then what we did with it.
TL;DR: ACP is to coding agents what LSP was to language tooling. Agents implement it once, clients implement it once. GPR treats your phone as an ACP client and runs eight agents through it: Cursor, Claude Code, Codex, Kiro, OpenCode, Qwen, Cline and Copilot.
The problem the Agent Client Protocol solves
Before ACP, every editor that wanted an agent wrote its own integration, and every agent that wanted to be in an editor did the same backwards. M editors, N agents, M × N bits of glue, each broken in its own way. ACP makes it M + N.
Same trick the Language Server Protocol pulled. It's why your editor can autocomplete Rust without anyone at your editor's company knowing much Rust.
How it works
For a local agent, the client starts the agent as a subprocess and they swap JSON-RPC messages over stdin and stdout. Remote transports over HTTP or WebSocket are still being worked out in the spec. The messages carry what a coding UI needs: the plan, tool calls and their results, file diffs, terminal output, permission requests, slash commands, model choices. Where it can, ACP reuses MCP's JSON shapes, and adds its own types for coding-specific UI like diffs.
The spec and SDKs are at agentclientprotocol.com. Not every agent speaks it natively. Claude Code and Codex get wrapped by small adapter binaries that translate.
In January Zed and JetBrains also launched the ACP Registry: an agent registers once and shows up in every ACP client, installed about the way you'd install an extension. Claude Code, Codex CLI, GitHub Copilot CLI and OpenCode were in it at launch. That's the point where ACP stopped being a Zed thing and started looking like the default.
Agent Client Protocol vs MCP
The names rhyme, so people mix them up.
| ACP | MCP | |
|---|---|---|
| Connects | A client (editor, phone) to the agent | The agent to tools and data |
| Typical messages | Plans, diffs, tool calls, permission requests | Tool calls, resources, prompts |
| Example | Zed or GPR driving Claude Code | Claude Code reading your database |
In a normal setup the editor talks ACP to the agent and the agent talks MCP to its tools. You use both.
How we found it
GPR doesn't ship its own coding agent. Nearly every developer already pays for one or two: Cursor, a Claude plan, ChatGPT for Codex, Copilot through work. Making them buy another before they can try GPR is friction, and paying twice. We wanted to reuse what people already have. We just didn't know how without writing and maintaining one integration per agent.
Then we watched a video where Ben Brandt from Zed and people from JetBrains walk through ACP. Our exact problem, solved for editors, and nothing in it required the client to be an editor.
A phone could be just another client.
What GPR does with ACP
GPR's daemon runs on your machine and talks ACP to the agent over stdio, same as Zed would. The daemon dials out to our relay over a WebSocket, so nothing on your machine listens for incoming connections, and the relay passes the same messages on to the app. It keeps the stream, so a phone that dropped off in a lift picks up from the last event it saw, and it sends a push when the agent needs you. So the phone isn't screen-scraping a terminal. It gets plans, tool calls, diffs and terminal output as structured messages, and that's why one mobile UI works for every agent.
The daemon recognises eight today: Cursor (cursor-agent), Claude Code, Codex, Kiro, OpenCode, Qwen, Cline, Copilot. We built GPR with four of them (Cursor, Claude Code, Kiro, OpenCode) and nobody had to agree on one. gpr discover tells you which are ready, which are installed but missing an adapter, which aren't installed. Pick one per workspace. Switch with a dropdown. We don't pull agents from the ACP Registry yet. Anything listed there already speaks the protocol, though, so adding one is a small job for us rather than a new integration.
Some things just fall out of using the protocol properly. The slash commands in the app are whatever the agent advertises over ACP, not a list we maintain, so a new command just shows up. Model switching uses ACP's config options, and if an agent also advertises a models slash command, the app hides it so there's one way to switch everywhere. Agents can send their own extension messages; Cursor and Kiro both do, and they were the first two we supported properly, in July. Not every extension earns its place. In September we hid Kiro's MCP status widget from the chat. It was noise.
Agent Client Protocol with Claude Code
People search for this specifically. Claude Code doesn't speak ACP natively. It goes through an adapter that sits next to the gpr binary, and the installer puts it there. That's also why it was late for us: Cursor and Kiro speak ACP out of the box and got proper support in July, while Claude Code (and Codex) landed on September 18.
The adapter route has one nice side effect. If you run Claude Code on an API key, or through OpenRouter or a company gateway, you set that in GPR's agents.json and it just works. Anthropic's own Remote Control refuses all of those setups. The Claude Code post has the details.
What the protocol doesn't fix
ACP standardises the conversation. It doesn't standardise how agents behave as processes, and running them unattended for hours shows it.
Agents that won't stop. Stop some agents halfway through startup and they ignore the polite signal and keep running. Start several at once and they can trip over the same config file. In August that combination left 52 agent processes on one of our machines, about 300 MB each (the Cursor post has the story). The daemon now gives an agent two seconds to exit, then kills it.
Agents that go quiet. Some stop talking mid-turn without saying why. GPR fails the task after 90 seconds of silence rather than wait forever, so it shows up on your phone as failed instead of sitting at "running" all afternoon.
These tools mostly weren't built to be long-running background processes, and a protocol can't change that. Somebody has to absorb it. For us that's the daemon.
Your keys stay where they are
Your own agent means your own login. Anthropic key, codex login, Cursor account, all stay on your machine, and any keys or gateway settings the daemon needs go in ~/.gpr/agents.json there too (reference). GPR's backend never sees them, and your model bill doesn't change.
Try it
GPR is free for projects, sessions, and the GitHub and Slack connections. You pay only for more workspaces or more tasks running at once. Get the app on Google Play, then:
curl -fsSL https://getpullrequest.com/install | bash
cd ~/code/your-repo && gpr setup
gpr discover
Agent-specific guides: Claude Code, Codex, Cursor. Running several at once across machines: parallel coding agents.
Keep reading
New here? The launch post, Your AI coding agent is stuck in a terminal you have to babysit. So we built GetPullRequest, is the why. The pillar, We ditched cloud AI coding agents. Our laptops were faster, and already paid for, is the how.
- Claude Code Remote Control is great. It's also not enough
- Codex CLI remote control: stop babysitting the terminal and let it ship PRs while you're out
- Cursor background agents charge you twice for compute you already own
- Run parallel coding agents on every machine you own, from one phone
- AI can run the software factory. It can't turn the lights off yet
Top comments (1)
This is a fantastic breakdown of why standardisation matters so much in this space. ACP really does feel like the LSP moment for AI agents—moving away from M × N custom integrations is the only way this ecosystem scales sustainably without fracturing into vendor lock-in. The way you mapped out the distinction between ACP (client-to-agent) and MCP (agent-to-tools) makes total sense. Brilliant move using a local daemon to handle the process quirks and letting a mobile app act as the client. Looking forward to seeing how the remote transport spec develops!.