Editor Integration

tapioca --acp speaks the Agent Client Protocol on stdio, so Zed and other ACP clients can drive Tapioca as their agent: streamed replies, tool calls with status, the todo list as a plan, and permission prompts rendered by the editor.

Zed

Point an ACP agent server at the binary in your Zed settings:

{ "agent_servers": { "Tapioca": { "command": "tapioca", "args": ["--acp"] } } }

Driving other agents

The protocol goes both ways. Tapioca is also an ACP client, so it can drive Claude Code, Gemini CLI or anything else that speaks it:

[[agents.external]]
name = "claude-code"
command = "claude"
args = ["--acp"]
  [agents.external.env]
  EXAMPLE = "value"

/connect lists them alongside providers — the screen answers one question, which is what this session can talk to. Picking one gives it a tab, and its work streams into the transcript like any other agent's.

Whatever it asks to run goes through your permission rules. A deny still denies, even under bypass. But the rules match against the command the agent said it was about to run, so they protect you from the agent's model, not from its binary — one that describes a call only in prose gets a prompt every time and is never granted standing permission, because there is nothing specific to grant. Connect ones you would trust with a shell, which is what launching one already is.

Probing without an editor

sh scripts/acp-probe.sh "your prompt" (in the Tapioca repo) drives the protocol from a shell and prints the updates an editor would have rendered.

Trust model

--acp speaks JSON-RPC on stdio, so the peer is whatever process launched Tapioca — normally your editor. It may supply its own MCP servers, which means commands to execute, and it chooses the working directory. That is not an escalation (a process that can spawn Tapioca can already run anything as you), but do not expose an --acp process's stdin to anything you would not trust with a shell. More in Sandboxing & Security.