When we introduced the Agent Client Protocol (ACP) in collaboration with Google’s Gemini CLI team, we did not anticipate how much pent-up demand there was for a protocol like this!

As of today, Zed supports Codex out-the-box via ACP. You can select it from the New Thread menu, just like Claude Code or Gemini CLI:

A walkthrough of OpenAI’s Codex in Zed.

Like our other ACP integrations, Codex via ACP is strictly about improving UI and keeping you in flow in your IDE of choice; the billing and legal/terms arrangement is directly between you and OpenAI. Zed does not charge for use of external agents like Codex, nor do prompts and code sent via Codex-ACP to OpenAI touch Zed’s servers! We’ve also separately open-sourced the codex-acp adapter so you can use it outside of Zed as well.

Learning from Different Agents

Every model behaves a bit differently than the others, and the same is true of agents. For example, some agents support switching models in the middle of a conversation, whereas others require sticking with the same model throughout. Some support viewing and resuming past conversations, whereas others have no concept of conversation persistence. ACP is designed to be flexible enough to work with a variety of agent capabilities, but the experience of using them still varies based on the agent’s implementation details.

A detail that came up when we were building the Codex ACP adapter was that the Codex agent runs terminal commands in its own process, and then streams output bytes from that terminal process to the client. In the past, we’ve had this reversed: the agent would send the client a request to run a terminal command (e.g. mkdir examples) and then the client would manage the actual running of that command.

Naturally, we want to keep the look and feel consistent no matter which agent you’re using, but this design difference between Codex and other agents makes certain details unavoidably different. For example, for other agents we can spawn terminals in pseudoterminal (PTY) mode. This means you can actually interact with the terminal right in the Agent Panel if the agent launches an interactive process, and it also means things like colorful terminal output tend to be enabled by default.

On the other hand, being in PTY mode means that an agent can get stuck. A classic example of this is when an agent tries to run git rebase --continue and the terminal pops up the configured editor, then waits for the programmer to make any edits (if desired) to the commit message. This can be nice for a human, but for an agent that’s waiting for the command to finish, it creates a deadlock. The process won’t proceed without interaction, and the agent won’t interact until the process completes! Having terminals work in non-PTY mode might result in fewer colors and less interactivity, but it also results in fewer cases of agents getting stuck.

Now that we’ve integrated agents that both enable and disable PTY mode, we can compare how the experience feels in both cases, and use that to inform our recommendations for future ACP integrations.

Which ACP Integration is Next?

In addition to Codex, we have already added support to Zed for Claude Code, Gemini CLI, and other agents, all via ACP. Since ACP is not specific to Zed, we’ve also seen it be adopted by editors like Neovim, Emacs, and now the JetBrains family of IDEs.

Now that the protocol has picked up enough adoption on its own, we’re happy to shift our focus to working with the community on the future of the protocol—as opposed to building ACP adapters ourselves like we did with Codex and Claude Code. We’re excited to see what amazing ACP integrations the community cooks up!

Looking for a better editor?

You can try Zed today on macOS, Windows, or Linux. Download now!

We are hiring!

If you’re passionate about the topics we cover on our blog, please consider joining our team to help us ship the future of software development.