guide · Claude Code and Codex

How to make Claude Code and Codex talk to each other across two machines

Install Murmur on both computers, pair them once with an invitation and a reply, and connect each assistant to its local Murmur MCP server. Claude Code on one machine then calls murmur_request to send Codex a question and wait for the answer; Codex on the other machine reads it with murmur_inbox and answers with murmur_send. Each message is signed and encrypted on the sender’s computer and decrypted only on the recipient’s; the server between them passes ciphertext. You need Node.js 22.13.0 or newer on both computers and a server both can reach.

Updated 29 September 2026 · Murmur 2.12.0

before you start

what you need

two computers

macOS, Windows or Linux. The Murmur app runs on Mac and Windows; the command-line tools also run on Linux. Each computer gets its own identity. The second computer can be a colleague’s, in your company or another one, or your own second machine.

Node.js 22.13.0 or newer

On both computers, from nodejs.org. Every Murmur 2.12.0 download needs it: the service stores messages with the SQLite module built into Node.js, which works without a flag from 22.13.0.

a server both computers reach

The two Murmur services exchange messages through a server with a public address. Use one run by someone you trust, or start your own: the repository has a Docker Compose file for it. Murmur does not create an invitation with a private or loopback server address.

an invitation and a reply

An invitation is one line that starts with MURMUR:. It carries the server address and can carry its access key, so pass it like a password, in a private message. The other side answers with a reply line; after that you are contacts.

Claude Code and Codex

Claude Code on one computer and the Codex CLI on the other. The same steps connect Claude Desktop and Codex Desktop on macOS, and either assistant can sit on either side.

step by step

from an invitation to the first answer

The app does steps 1–6 with buttons; each step also shows the command for a terminal. The home page walks through the app version in the first five minutes. The commands below use the npm install; keep the same absolute identity folder for every command on a computer.

install Murmur on both computers

On Mac or Windows, download the app from the v2.12.0 release page and follow the installation steps on the home page. In a terminal, install the command-line tools from npm:
```
npm install --global @murmurv2/cli@2.12.0
```
create an identity and an invitation

On the first computer, choose to invite a colleague in the app. In a terminal, create the identity once and write the invitation to a new private file:
```
murmur init --agent-id alice --broker-url tls://server.example.com:4222 --token-file /absolute/private/server-token.txt --data-dir /absolute/murmur-identity
murmur invite --out /absolute/private/invitation.txt --data-dir /absolute/murmur-identity
```
Send the invitation in a private message. It can contain the server access key: never post it in a group chat or an issue.
the other side accepts

On the second computer, choose “I have an invitation” in the app and paste the line. Murmur creates that identity and returns a reply line. In a terminal:
```
murmur join --agent-id bob --invite-stdin --data-dir /absolute/murmur-identity
```
The reply goes back the same private way. It holds public keys only, not the server access key and not the private keys.
import the reply

Back on the first computer, paste the reply in the app, or run:
```
murmur add-peer --reply-stdin --data-dir /absolute/murmur-identity
```
Now you are contacts. Importing the reply proves only your own side; the other side is proven by a message that comes back in step 7.
start the service on both computers

The app starts it for you; on Windows, installing the service asks for administrator rights separately. In a terminal:
```
murmur service install --data-dir /absolute/murmur-identity
murmur service start --data-dir /absolute/murmur-identity
```
The service carries messages in the background, also while the app window is closed.
connect Claude Code and Codex

In the app, choose your assistant. In a terminal, find the installed assistants and configure the one on this computer, then reload it:
```
murmur clients detect --data-dir /absolute/murmur-identity
# on the computer with Claude Code:
murmur clients configure --client claude-code --data-dir /absolute/murmur-identity
# on the computer with Codex:
murmur clients configure --client codex-cli --data-dir /absolute/murmur-identity
```
For Claude Code this adds the Murmur MCP server to ~/.claude.json and a Stop hook for wake-up to ~/.claude/settings.json. For Codex it adds the server to ~/.codex/config.toml. Other settings stay as they were, and a backup of the old file is saved.
check the channel

From the first computer:
```
murmur doctor --peer bob --timeout 60000 --json --data-dir /absolute/murmur-identity
```
In 2.11 the contact’s service answers this signed, encrypted test by itself. A returned answer proves the channel in both directions; it does not test the assistant on the other side.
ask the first question

In Claude Code, ask in plain words, for example: “ask bob through Murmur to review the migration plan and reply”. Claude calls murmur_request, which sends the message and waits up to 45 seconds. On the other computer, Codex reads the question with murmur_inbox and answers with murmur_send in the same conversation. If Codex is idle and wake-up is not set up for it, the question waits until Codex next runs a turn, and the answer then arrives in Claude Code’s inbox.

in Claude Code

tools for messages, a hook for wake-up

After configuration, Claude Code sees the tools of the Murmur MCP server. You rarely name them: ask in plain words and Claude picks the tool.

tool	what it does
`murmur_request`	Sends an encrypted message and waits up to 45 seconds for the answer. A slower answer returns `awaiting_reply` with the conversation ID and the delivery state; the answer is then read with `murmur_inbox`, not by sending again.
`murmur_send`	Sends an encrypted message and returns as soon as it is queued.
`murmur_inbox`	Reads incoming messages that the service has verified, decrypted and stored.
`murmur_peers`	Lists your contacts and whether their keys are present.
`send_message`, `list_conversations`, `search_messages`	Work with the local conversation store: save a message, list conversations, search stored messages.

The call Claude makes for a question looks like this:

murmur_request(to: "bob", text: "Please reply to confirm the connection", timeout_ms: 45000)

Only a message that the contact’s service has acknowledged is reported as delivered; queued and retrying messages stay pending.

The same configuration installs a Stop hook. When Claude Code has finished a turn and sits idle, a message from a contact starts a new turn by itself, for as long as the hook is allowed to listen after that turn: eight hours from 2.12.0 (about ten minutes in 2.11.0), see the wake-up page. How it works and where it stops: wake-up for an idle Claude Code session.

in Codex

the same tools, a different wake-up

Codex gets the same MCP tools through its configuration file, ~/.codex/config.toml (or the one under CODEX_HOME). It reads a question with murmur_inbox and answers with murmur_send, using the conversation ID of the incoming message, so the answer reaches the murmur_request that is waiting for it.

Codex has no Stop hook. On macOS and Linux, the Murmur service can start a turn in Codex through codex app-server over a Unix-domain socket. It is set up by hand in the identity’s configuration and is not part of clients configure. On Windows it is not available: Codex answers when it next runs a turn. Details are on the wake-up page.

In Codex Desktop on macOS, Murmur can deliver an incoming message to the exact task that started the conversation. This is opt-in and described in codex-desktop-queue-wake.md.

what happens on the way

signed, encrypted, acknowledged

Claude Code calls murmur_request. The Murmur MCP server on your computer encrypts the text for the contact with X25519 key agreement and XChaCha20-Poly1305, signs the envelope with Ed25519 and puts it into a local SQLite outbox.
Your service publishes the encrypted envelope to the server. Until the envelope is acknowledged, the service retries it; a message that keeps failing lands in a dead-letter queue where you can see it, instead of disappearing.
The server passes the envelope to your contact’s service. It sees the addressing (sender, recipients, conversation ID, time) and the size. The text is ciphertext to it, and the private keys never leave the two computers.
The contact’s service checks the signature, decrypts the text and stores it, then returns a signed receipt bound to that message. Only this receipt makes your side report the message as delivered.
Codex reads the message and answers. The answer travels the same way back, and murmur_request hands it to Claude Code.

Both sides keep their own copy of the conversation in a local SQLite database. Decrypted text is stored there unencrypted and protected by file permissions, so SECURITY.md recommends disk encryption. The message format is specified in protocol-v1.md.

Claude Code’s own messaging

how this differs from cross-session messaging

Since v2.1.224, Claude Code can list and message your other Claude Code sessions with its ListAgents and SendMessage tools (Anthropic documentation). Sessions on the same computer talk over a local socket. Your sessions on other computers, and your cloud sessions, are reached through Anthropic servers while the sessions are connected to Remote Control, which needs a claude.ai sign-in. An idle receiving session starts a new turn with the message.

	Claude Code cross-session messaging	Murmur
connects	your own Claude Code sessions	assistants that speak MCP: Claude Code, Codex, Claude Desktop, Codex Desktop, others by hand
across computers	yes, your sessions connected to Remote Control, and cloud sessions	yes
across people and organizations	the documentation describes your own sessions only	yes: two people pair with an invitation and a reply
route between computers	Anthropic servers	a server you choose or run
encryption between computers	end-to-end encryption is not described in the documentation	end to end: X25519 and XChaCha20-Poly1305, Ed25519 signatures
setup	built in and on by default from v2.1.224 (v2.1.234 on native Windows)	install on both computers, a server, one pairing

If every session is Claude Code and all of them are yours, the built-in feature is the shorter path. Murmur is for the other cases: Claude Code talking to Codex, two people or two companies, or messages that should travel end-to-end encrypted through a server you choose. A wider comparison: Murmur compared with other ways to connect assistants.

questions

short answers

Do both computers need Murmur?

Yes. Each computer runs its own Murmur service with its own identity and keys, and each assistant talks only to its local service. The two services exchange encrypted messages through a server; the assistants never connect to each other directly.

Do I need my own server?

You need a server that both computers reach at a public address. It can be run by someone you trust, who gives you access through an invitation, or by you: the repository includes a Docker Compose file for it. Murmur does not create an invitation with a private or loopback server address.

Can the server read the messages?

No. Each message is encrypted on the sender’s computer with X25519 key agreement and XChaCha20-Poly1305 and signed with Ed25519; only the recipient’s service decrypts it. The server sees the addressing (sender, recipients, conversation ID, time) and the size of each message.

What happens if Codex is not running when the question arrives?

While the contact’s Murmur service runs, it stores the message and returns a signed receipt, so your side reports it as delivered. The question waits until Codex next runs a turn, or until wake-up through the Codex app-server starts one on macOS or Linux. murmur_request waits up to 45 seconds, then returns awaiting_reply with the conversation ID; the later answer is read with murmur_inbox.

Does it work on Windows?

Yes. The app, the service and the MCP server run on Windows, and Claude Code there gets the same Stop hook for wake-up. Wake-up for Codex is not available on Windows in 2.11, so Codex on Windows answers when it next runs a turn.

How is this different from Claude Code’s cross-session messaging?

Claude Code’s built-in messaging connects your own Claude Code sessions, on one computer or, through Anthropic servers and Remote Control, on several. Murmur connects any assistant that speaks MCP, Codex included, between different people and organizations, through a server you choose, with end-to-end encryption.

more

related guides

In the repository: README quick start · setup-onboarding.md · CLI guide · wake-native.md · release v2.12.0