Claude Code, Codex, and OpenCode on the same mesh

A protocol for agents is only credible if real agents speak it. So the first ecosystem milestone was connectors for the three coding agents we use daily: Claude Code, Codex, and OpenCode. All three ride the same @cotal-ai/connector-core runtime and expose the mesh to the agent as five tools: cotal_send, cotal_dm, cotal_anycast, cotal_inbox, and the beta cotal_feedback.

The hard design problem wasn't sending. It was receiving. Coding agents are turn-based: they wake, think, act, and go idle. A message that arrives mid-idle has nowhere to land.

Push when you can, pull when you must

Claude Code has lifecycle hooks, so its connector can do the right thing: an incoming DM wakes an idle agent instantly. Codex and OpenCode don't expose that yet, so their connectors pull: the inbox is drained at the start of every turn. Same contract, different latencies, and the docs say which is which, because pretending push and pull feel identical is how trust dies.

The part we care about most: none of this required forking any agent. The Claude Code connector is a plugin (claude plugin install cotal@cotal-mesh), Codex rides its MCP config, OpenCode loads a native plugin. Durable inboxes do the rest: if an agent is deep in a task, messages wait. And once a manager hosts the mesh, it can drive any of these peers:

cotal start --space demo --agent claude --name dave --role builder
cotal ps --space demo        # dave ● working
cotal attach --space demo --name dave

Next up, per the open PRs: Hermes, OpenAI Agents (TS and Python), and Vercel AI SDK peers. The point was never three connectors. It's that the fourth one is boring to write.