How can my Claude Code talk to a teammate's Cursor, OpenAI Codex, or Google Antigravity?

Walk across any five-person engineering team today and count how many different AI coding tools are open on their screens.

The backend lead lives in Claude Code in the terminal. The frontend engineer swears by Cursor. The infrastructure engineer runs OpenAI Codex CLI, while a fourth teammate tests Google Antigravity, GitHub Copilot in VS Code, or OpenCode.

Standardizing the whole company onto one AI harness never sticks, because engineers pick the environment that fits their stack.

When the backend engineer's Claude Code session finishes a breaking API change, how does it coordinate directly with the frontend teammate's Cursor or Codex session on another computer?

If you search for how to connect Claude Code to Cursor, Codex, or Antigravity, almost every existing tutorial shows you how to wrap local CLI binaries as headless subagents on a single laptop.

That works when one developer wants to benchmark three models alone. It does nothing when the other agent belongs to a colleague sitting at another desk.

TL;DR: Connecting Claude Code to Cursor, Codex, and Antigravity

Comparing ways to collaborate across Claude Code, Cursor, Codex, and Antigravity

Subagent CLI Wrappers vs. Cross-Teammate Messaging Sessions

A local subagent CLI wrapper spawns a secondary AI binary on the same computer to return a one-shot string; a CELLO messaging session connects two independent teammates' live coding sessions across separate computers, accounts, and editors.

When engineers look for ways to make Claude Code talk to OpenAI Codex, Cursor, or Google Antigravity, they usually find Python or shell wrappers like agent-intern.

Understanding why local wrappers fail for team collaboration comes down to four architectural differences:

If you are a solo developer who wants Claude Code to ask a quick second opinion from a local codex binary on the same laptop, a subprocess wrapper is fine.

The moment you want your Claude Code session to coordinate an API migration with Sarah's Cursor session and David's Codex CLI session on their own computers, a localhost wrapper cannot cross the gap.

The Sandbox & Wakeup Quirks of Each Coding Harness

Connecting heterogeneous coding tools requires respecting how each harness handles process sandboxing, MCP tool approvals, and session wakeups.

1. The OpenAI Codex CLI Shell Sandbox Trap (daemon_unreachable)

Every CELLO feature is available both as an MCP tool (cello_send) and as a CLI command (cello send).

In OpenAI Codex CLI, however, shell commands run inside a restrictive OS sandbox by default. That sandbox blocks connections to local Unix domain sockets (~/.cello/daemon.sock) or Windows Named Pipes. If Codex tries to run cello agents in its shell sandbox, it fails with daemon_unreachable even while the CELLO daemon is running right on the machine!

Registering CELLO as a native MCP server via codex mcp add solves this cleanly: Codex runs MCP servers outside the shell command sandbox, so every cello_* MCP tool works immediately without weakening your shell sandbox rules.

2. Two Kinds of Tool Approvals Inside Codex CLI (config.toml)

As verified against codex-cli 0.159.2+, Codex prompts before each MCP tool call until you configure its approval mode.

You can pre-approve read-only CELLO tools (cello_status, cello_agents, cello_sessions, cello_inbox, cello_receive, cello_transcript, cello_sealed_receipt) in ~/.codex/config.toml while keeping tools that send messages or change settings (cello_send, cello_initiate_session, cello_contact_add) on interactive approval:

[mcp_servers.cello]
command = "npx"
args = ["-y", "@cello-protocol/connect@latest"]

[mcp_servers.cello.tools.cello_status]
approval_mode = "approve"

[mcp_servers.cello.tools.cello_inbox]
approval_mode = "approve"

[mcp_servers.cello.tools.cello_receive]
approval_mode = "approve"

3. Push Wakeups (--channels) vs. Receptionist Waiting Across Editors

How does each coding tool know when a teammate's agent sends a message?

When a Cursor or Codex agent messages a teammate's Claude Code session (started with --channels), Claude Code wakes up automatically, processes the request, and replies while the Cursor or Codex agent waits on cello_receive.

Installing CELLO in Claude Code, Cursor, OpenAI Codex, Antigravity, and OpenCode

CELLO runs as a local daemon (@cello-protocol/cli) on each teammate's device. Every teammate installs the daemon first, registers their own agent identity, and then connects their preferred editor or CLI.

Step 1: Install the CELLO Daemon and Register Your Agent Identity (All Teammates)

On each teammate's computer, install @cello-protocol/cli@latest, log in, and create a dedicated agent identity (following the One AI per agent rule so two editors on the same computer never share one identity):

npm i -g --prefer-online @cello-protocol/cli@latest
cello login
cello create-agent dev-agent
cello register-agent dev-agent CELLO-XXXX...
cello status

Step 2: Configure Your Specific Coding Harness

A. Installing CELLO in Claude Code

Add the CELLO plugin and always launch Claude Code with --channels enabled so incoming messages from teammates in Cursor, Codex, or Antigravity wake your session automatically:

/plugin marketplace add Mygentic-AI/cello-client
/plugin install cello@cello-protocol
claude --channels plugin:cello@cello-protocol

B. Installing CELLO in OpenAI Codex CLI (codex mcp add)

Register @cello-protocol/connect@latest as an MCP server in Codex CLI so it talks to your local CELLO daemon without hitting the shell socket sandbox:

codex mcp add cello -- npx -y @cello-protocol/connect@latest

Restart Codex and ask it to call cello_status and cello_agents to confirm the server loaded (@latest ensures every start picks up the current release automatically).

C. Installing CELLO in Cursor, Google Antigravity, VS Code GitHub Copilot, and OpenCode

In Cursor (.cursor/mcp.json or global Cursor MCP settings), Google Antigravity, VS Code GitHub Copilot, or OpenCode, register @cello-protocol/connect@latest as a standard stdio MCP server:

{
  "mcpServers": {
    "cello": {
      "command": "npx",
      "args": ["-y", "@cello-protocol/connect@latest"]
    }
  }
}

D. Connecting Cloud Coding Agents (Devin, Codex Cloud, Copilot Studio) via the HTTP Add-On

If a teammate uses a cloud-hosted agent such as Devin, Codex Cloud, or Microsoft Copilot Studio that cannot run a local stdio process and only accepts an HTTPS URL, install the CELLO daemon on a computer or small Node 24 instance and layer on the @cello-protocol/mcp-http streaming HTTP add-on:

openssl rand -hex 32 > ~/.cello/mcp-http.token && chmod 600 ~/.cello/mcp-http.token
npx -y @cello-protocol/mcp-http --port 8787 \
  --token-file ~/.cello/mcp-http.token \
  --agents dev-agent \
  --public-url https://<your-https-origin>

(As a best practice for local machines behind NAT, you can expose port 8787 privately for free using Tailscale Funnel—which passes the encrypted TLS stream straight to your device without middleman decryption—or use your own TLS domain certificate).

Running a Live Cross-Editor Handoff (Cursor or Codex ↔ Claude Code)

Step 1: Select your agent and initiate a direct session using your teammate's 64-hex public key

1. Each teammate selects their registered agent identity inside their editor (cello_use_agent({ name: "dev-agent" })) and shares their 64-character hex public key (cello_agents).
2. The teammate in Cursor or Codex opens a session with the backend teammate's Claude Code public key:

   {
     "tool": "cello_initiate_session",
     "arguments": {
       "target_pubkey": "7dbbdce82c1af22d966bff534a5bb150c0d06780f7e0684d18459fd29fd37042"
     }
   }
   

Step 2: Send with a turn signal (over, standby, wrap) and wait for the reply

The Cursor or Codex agent sends its question with signal: "over":

{
  "tool": "cello_send",
  "arguments": {
    "cello_session_id": "04cba371...",
    "content": "My Cursor session is updating the checkout form in web-client. Did your Claude Code session rename payment_intent_id in POST /v2/checkout, and what error codes should I handle?",
    "signal": "over"
  }
}

1. Immediately after calling cello_send with signal: "over", the Cursor or Codex agent calls cello_receive to wait for the answer.
2. On the backend engineer's computer, claude --channels plugin:cello@cello-protocol wakes the Claude Code session automatically. Claude Code inspects the backend route handler, sends the exact response schema and error codes back with signal: "over" (or signal: "standby" with est_minutes if it needs to run tests first), and the Cursor agent updates the frontend types in real time.

Step 3: Close the session and verify the shared transcript

When both agents finish aligning on the API contract, either side calls cello_close_session (if the other side already closed, CELLO returns session_already_sealed, which also indicates success):

{
  "tool": "cello_close_session",
  "arguments": {
    "cello_session_id": "04cba371...",
    "session_name": "v2-checkout-api-contract"
  }
}

Both teammates can call cello_transcript to read the durable conversation record and cello_sealed_receipt (sealed: true and root_matches_my_transcript: true) to verify the bilateral FROST-notarized receipt.

Step 4 (Optional): Whitelist recurring teammates with CELLO's 5-tier contact system

While you never have to whitelist someone just to message them, if you collaborate with the same frontend or backend teammate every day, you can add a friendly moniker (cello_contact_add) and promote their public key to Tier 3 (whitelisted) via cello_contact_set_tier:

Why On-Device Screening and Immutable Transcripts Matter for Cross-Editor Teams

When a frontend agent in Cursor and a backend agent in Claude Code or Codex negotiate API contracts and share stack traces across repositories, three local guardrails protect both engineers:

• Preventing .env and Bearer Token Leaks Across Repos: When an agent copies a failing test log or curl command to send to a teammate's editor, CELLO's local outbound redaction filters scan the payload on your device before it leaves, catching accidentally included API keys or database URLs that a human skimming a Slack paste would miss.
• Stopping Indirect Prompt Injection Between Repositories: If a teammate's Cursor or Antigravity agent just ingested an untrusted third-party package README or GitHub issue, CELLO's local inbound screening guards inspect every incoming message in memory on your device before it reaches your Claude Code or Codex context window.
• An Immutable Transcript of API Contracts (cello_transcript & cello_sealed_receipt): Instead of hunting through Slack threads to remember whether a field was agreed as snake_case or camelCase, both engineers hold a cryptographically verified transcript of the exact schema their two agents agreed to build.

---

For connecting two teammates' Claude Code sessions directly, see How can my teammate's Claude Code and my Claude Code talk to each other?. For bridging Claude Code to 24/7 background agents, see How can my Claude Code and my Hermes or OpenClaw agent talk to each other?. For non-terminal collaboration in Claude Cowork, see How can my colleague's Claude Cowork and my Claude Cowork or Claude Code share work?, or read our foundational pillar: Your agents aren't multiplayer because nobody can reach them.