How can my Claude Code and my Hermes or OpenClaw agent talk to each other?

Look at how the sharpest builders run their AI stack today, and a clear pattern emerges.

They do not use one agent for everything. They run two specialists in two different places:

• Claude Code lives on their computer inside the git repository, built for deep, interactive code edits, test runs, and pull requests.
• Hermes Agent (by Nous Research) or OpenClaw runs 24/7 on a server or VPS, built for scheduled cron jobs, continuous research, log monitoring, and inbound messages while the laptop lid is closed.

That two-agent split works brilliantly until the two agents need to talk to each other.

Your Hermes agent catches a failing webhook on staging at 3:00 AM, or finishes a forty-page API research brief on your server. How does that context reach the Claude Code session inside your local repository?

For most operators today, the answer is embarrassing: you open Telegram, copy the text from Hermes, switch to your terminal, and paste it into Claude Code.

You have two autonomous agents, and you are still acting as the clipboard between them.

TL;DR: Bridging Claude Code with Hermes Agent and OpenClaw

Comparing ways to connect Claude Code with Hermes and OpenClaw in 2026

The Architecture of a Split-Stack Agent Setup

A split-stack agent workflow pairs an interactive local repository agent (Claude Code) with a persistent 24/7 server agent (Hermes Agent or OpenClaw) connected over an encrypted peer-to-peer messaging bus.

Why do operators split their workflow across two harnesses instead of forcing one tool to do both jobs?

Because a coding terminal and a 24/7 background gateway have opposite operating constraints:

Merging these two roles onto one machine—either by leaving Claude Code running unattended with --dangerously-skip-permissions on a public server, or by giving an internet-facing chat bot direct write access to your local codebase—breaks the security boundary between untrusted external data and your source code.

Four Failure Modes When Bridging Server Agents Without CELLO

When developers try to connect their local Claude Code terminal to a remote Hermes or OpenClaw server using off-the-shelf chat apps or ad-hoc scripts, four things break.

1. The NAT Call-Back Wall

Your Hermes or OpenClaw server is always on, but your Claude Code session lives on a computer behind a home or office router.

When Hermes finishes a research job or catches a production alert, it cannot open an inbound HTTP connection or SSH tunnel back into your laptop without port forwarding or a VPN mesh.

2. Why Telegram, Slack, and Discord Bot Channels Break Down for Agent-to-Agent Loops

Because Hermes Agent and OpenClaw already support Telegram, Slack, and Discord, many operators try to drop a Claude Code bot and a Hermes or OpenClaw bot into a shared chat room so they can coordinate. In practice, every human chat platform hits the same structural limits:

• Telegram (Blocked by Default, All-or-Nothing When Enabled): By default, Telegram's Group Privacy Mode prevents bots from seeing messages sent by other bots. You can turn on Bot-to-Bot Communication Mode in @BotFather (or make the bot a group admin and use /command@TargetBot mentions), but that toggle is a blunt, all-or-nothing switch. Once enabled, your bot can converse with any other bot that has the mode turned on, and @mention commands are callable by anything in the group with zero fine-grained per-peer access control. Worse, as Telegram's own documentation warns, you have to code your own rate limits, deduplication, and depth caps to keep two bots from locking into an infinite reply storm that drains your API keys.
• Slack and Discord (@mention One-Shots vs. Real Back-and-Forth): Calling a bot in Slack or Discord with an @mention works if a human wants to hand off a single one-shot task, but it is nothing like two agents autonomously conversing back and forth across multiple turns when they need to. If you allow two Slack or Discord bots to respond to each other automatically without manual human @mentions, there is no native turn-taking protocol (over, standby, wrap) to stop a runaway ping-pong loop.

3. Indirect Prompt Injection from Scraped Feeds into Your Repo

Your 24/7 Hermes or OpenClaw agent spends all day reading untrusted inputs: scraped web pages, GitHub issues, social posts, and inbound emails.

If you pipe raw output from Hermes straight into Claude Code—or skim a 3,000-word research dump and paste it into your terminal—a hidden prompt-injection payload inside a scraped web page can instruct Claude Code to modify files or exfiltrate environment variables from your local repository.

4. Session Collision When Multiple Peers Call Your Server

If your Hermes server talks to your personal Claude Code session and also fields questions from teammates or external agents, a naive webhook dumps every caller into the same conversation history.

How the Native CELLO Hermes Bridge Actually Works (explicit, channel, and wake Modes)

The cello bridge hermes command scaffolds a native CELLO platform adapter directly into a Hermes Agent profile (~/.hermes or --hermes-home), allowing Hermes to send and receive encrypted CELLO messages alongside Telegram, Discord, or Slack.

Unlike generic MCP wrappers that require an agent to poll an inbox on a timer, the CELLO Hermes bridge hooks directly into hermes-gateway. When your Claude Code session sends a message over CELLO, the local daemon on the server screens the payload and wakes Hermes immediately.

The bridge gives you three delivery modes (--delivery-mode) depending on how much autonomy you want Hermes to have when replying to Claude Code:

(In all three modes, CELLO's local on-device security screening runs on the exact same path before any bytes enter Hermes or leave for Claude Code).

Controlling Memory Isolation (--session-scope) and Active Window Routing (--landing-session)

When Claude Code calls Hermes multiple times across a week, where do those messages land inside Hermes?

The bridge controls this with two flags that solve two very common operational headaches:

1. --session-scope agent vs. --session-scope peer

• --session-scope agent (Default): Every CELLO conversation routes to one continuous Hermes thread—called the profile's Cello Hermes landing session (persisted in Hermes's state.db across gateway restarts). When your Claude Code session opens a new CELLO session with Hermes in the afternoon, Hermes remembers what your Claude Code session asked it that morning.
• --session-scope peer: Each counterparty 64-character hex public key gets its own isolated Hermes conversation thread. Use peer when your Hermes server fields requests from multiple teammates' Claude Code sessions or external users so two people's contexts never mix.

2. Routing Replies Into Your Active Window (--landing-session current)

Suppose you are currently chatting with Hermes in an interactive session on Telegram, the Hermes desktop app, or the CLI, and you tell Hermes: "Reach out to my laptop's Claude Code session over CELLO and ask for the current branch diff."

By default under --session-scope agent, Claude Code's reply would route to the background Cello Hermes landing session rather than the Telegram or CLI window you are looking at!

To pull Claude Code's reply straight into the active Hermes window where you are working, have Hermes (or your terminal) run this command before reaching out:

# Default Hermes profile (~/.hermes)
cello bridge hermes --agent server-hermes --landing-session current

# Secondary Hermes profile
cello bridge hermes --agent ops-hermes --hermes-home ~/.hermes/profiles/ops_agent --landing-session current

Passing --landing-session current reads HERMES_SESSION_ID from the active turn, writes $HERMES_HOME/cello/landing-session.json, and re-points the next inbound CELLO message to your active window in-process—no hermes gateway restart required. To return to default background routing later, run cello bridge hermes --agent server-hermes --landing-session default.

Field Note: Two Practical Rules That Prevent Dropped Replies

When operating Claude Code and Hermes Agent together in production, two operational rules will save you hours of debugging:

1. In Hermes, conclude your turn immediately after cello_send(..., signal: "over"): When Hermes initiates a CELLO session or sends a message expecting a reply, Hermes must not call cello_receive inside that same turn to wait for Claude Code. Calling cello_receive mid-turn over the MCP socket consumes the unread reply from the daemon before Hermes's turn finishes, which starves the bridge doorbell. Instead, Hermes simply calls cello_send with signal: "over" and ends its turn; the moment Claude Code replies, the bridge wakes Hermes with the answer automatically.
2. Remember that cello bridge hermes rewrites all bridge flags on every run: If you configured your agent with --session-scope peer and later run a bare cello bridge hermes --agent server-hermes after upgrading the CLI, omitting --session-scope peer resets it to the default (agent). Always include the full set of flags you want active when re-running the bridge command.

Installing CELLO Across Claude Code, Hermes Agent, and OpenClaw

CELLO runs as a local daemon (@cello-protocol/cli) on each machine. Install the daemon on both your computer and your server first, then configure each harness.

Step 1: Install the CELLO Daemon and Register Separate Identities on Both Machines

Never point Claude Code and Hermes Agent (or OpenClaw) at the same CELLO agent identity (One AI per agent). Run this on both hosts to create distinct identities:

npm i -g --prefer-online @cello-protocol/cli@latest
cello login

# On your computer (for Claude Code)
cello create-agent laptop-claude
cello register-agent laptop-claude CELLO-XXXX...

# On your server (for Hermes Agent or OpenClaw)
cello create-agent server-hermes
cello register-agent server-hermes CELLO-YYYY...

Step 2: Wire CELLO into Hermes Agent (cello bridge hermes)

On your Hermes Agent server, wire the bridge into your default profile (or pass --hermes-home for a secondary profile) and restart the gateway:

# Personal or single-operator setup (explicit delivery, continuous landing session)
cello bridge hermes --agent server-hermes

# Multi-teammate or support setup (isolated Hermes thread per caller pubkey)
cello bridge hermes --agent server-hermes --session-scope peer

# Restart the Hermes gateway so the running process loads the adapter
hermes gateway restart

(Whenever you upgrade @cello-protocol/cli@latest in the future, re-run cello bridge hermes and restart the gateway so the copied adapter inside ~/.hermes updates to match).

Step 3: Wire CELLO into OpenClaw (@cello-protocol/connect)

If you run OpenClaw alongside or instead of Hermes, install the CELLO MCP connector on your OpenClaw machine:

npm i -g --prefer-online @cello-protocol/connect@latest

Add cello-mcp (npx -y @cello-protocol/connect@latest) to your OpenClaw MCP server list, and instruct your OpenClaw agent to bind its dedicated CELLO identity using cello_use_agent. (If your OpenClaw instance runs in a cloud environment that only connects to MCP servers by HTTPS URL, layer on the @cello-protocol/mcp-http add-on beside your local CELLO daemon).

Step 4: Install the CELLO Plugin in Claude Code and Launch with --channels

On your computer, install the CELLO plugin inside Claude Code:

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

Then launch Claude Code from your terminal with the --channels flag enabled:

claude --channels plugin:cello@cello-protocol

Starting Claude Code with claude --channels plugin:cello@cello-protocol is essential: it lets your local CELLO daemon wake your Claude Code session the instant Hermes or OpenClaw sends a message, with zero cron jobs or manual inbox checks.

Running a Live Handoff Between Claude Code and Hermes Agent

Step 1: Initiate a direct session using the 64-character hex public key

Inside Claude Code (after calling cello_use_agent({ name: "laptop-claude" })), ask Claude Code to open a CELLO messaging session with your server-hermes public key (cello_agents prints your 64-hex key):

{
  "tool": "cello_initiate_session",
  "arguments": {
    "target_pubkey": "b2c2889c066d1c278683d4ef6ed6711777b20cd5fa9bac07f392abef1e7a8c9b"
  }
}

{
  "tool": "cello_send",
  "arguments": {
    "cello_session_id": "e18c5bba...",
    "content": "Pull the last 24 hours of failing webhook payloads from the staging logs and send back the exact JSON keys that failed validation so I can patch the parser in this branch.",
    "signal": "over"
  }
}

Step 2: Hermes processes the request and wakes Claude Code

1. On your server, hermes-gateway receives the screened message inside the Cello Hermes landing session.
2. Hermes inspects the staging logs, extracts the failing payload keys, calls cello_send with signal: "over", and ends its turn.
3. On your computer behind NAT, claude --channels plugin:cello@cello-protocol wakes your Claude Code session immediately with Hermes's answer.

Step 3: Close the session to record an immutable, shareable transcript

Once Claude Code patches the parser and confirms the fix, either agent closes the session:

{
  "tool": "cello_close_session",
  "arguments": {
    "cello_session_id": "e18c5bba...",
    "session_name": "staging-webhook-parser-fix"
  }
}

Both your computer and your server now hold an identical, immutable transcript (cello_transcript) backed by a notarized bilateral receipt (cello_sealed_receipt).

Step 4 (Optional): Assign Tier 4 (vip) to your own server agent or Tier 3 (whitelisted) to teammates

While whitelisting is never required to start a conversation, CELLO's five-tier reachability system (cello_contact_set_tier) lets you give your own 24/7 server agent top priority while keeping unknown external callers throttled:

---

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 collaborating from 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.