According to Opus, ACP is designed specifically for IDE clients (with coding agent “servers”), and there’s some impedance mismatch here that would need to be resolved for one agent cli to operate as a client. I havent validated this though.

—-

1. ACP Servers Expect IDE-like Clients The ACP server interface in Claude Code is designed for: ∙ Receiving file context from an IDE ∙ Sending back edits, diagnostics, suggestions ∙ Managing a workspace-scoped session It’s not designed for another autonomous agent to connect and say “go solve this problem for me.”

2. No Delegation/Orchestration Semantics in ACP ACP (at least the current spec) handles: ∙ Code completions ∙ Chat interactions scoped to a workspace ∙ Tool invocations It doesn’t have primitives for: ∙ “Here’s a task, go figure it out autonomously” ∙ Spawning sub-agents ∙ Returning when a multi-step task completes

3. Session & Context Ownership Both tools assume they own the agentic loop. If OpenCode connects to Claude Code via ACP, who’s driving? You’d have two agents both trying to: ∙ Decide what tool to call next ∙ Maintain conversation state ∙ Handle user approval flows

opencode acp -- start ACP (Agent Client Protocol) server

[flagged]