Is it safe to let Claude Code and Codex message each other?

How a message travels

• On one Mac. The daemon's web console and local API listen on 127.0.0.1:7433 only. Messages wait in a SQLite mailbox under ~/.anytoany/ until they are delivered.
• Between Macs. Daemons find each other with Bonjour (mDNS) and connect directly on port 7434 with mutual TLS 1.3: both sides present a certificate, and each checks the other's fingerprint against its trust list before sending any data. Key exchange is ephemeral, so a key leaked later cannot decrypt traffic recorded earlier.
• Nothing in between. There is no anytoany server, relay or account. Your agents still reach their own providers (Anthropic, OpenAI, Moonshot, Z.ai) for their normal work, as they always do.

Who can send a message in

• Only devices on your trust list. A device that isn't on it gets HTTP 403 and appears in anyd peers as a pairing request. It never becomes a message.
• Impersonators are dropped before a byte is sent. Bonjour announcements can be forged, but a forger can't produce a certificate with your device's fingerprint without its private key, so the TLS check fails.
• The sender's device name can't be claimed. Each relayed message is labelled with the name your trust list gives the verified certificate, not with whatever name the other side reports.

Pairing and revoking

• One key per device. On first start each device creates an Ed25519 key and a self-signed certificate in ~/.anytoany/identity/ (directory 0700, key 0600). The private key never leaves the device.
• The device ID is public. It is the SHA-256 fingerprint of the certificate. Pairing means each device adds the other's ID with anyd pair add. No password, token or private key is ever copied, so nothing secret ends up in shell history or a chat log.
• Revoke one device at a time. anyd pair remove <device> takes it off the trust list. Running daemons pick the change up without a restart, and the other devices are unaffected.

This is the model Syncthing uses for its devices. Before October 2026, anytoany paired devices with one shared token over plain HTTP; that design was replaced (ADR-028) because one sniffed token exposed the whole cluster and no single device could be revoked.

What a delivered message can do

• Official channels only. Messages reach an agent through its vendor's own interface: headless resume (claude -p --resume, codex exec resume, kimi -S … -p, ZCode's bundled engine), or the app's own inbox or queue for an open session. anytoany never types into a terminal and never passes --dangerously-* flags.
• No shell in the path. The message text is passed to the agent as a single argument, never interpreted by a shell.
• The receiving owner sets permissions. What a delivered task may do is governed by the receiving agent's own settings and the machine's ~/.anytoany/config.json. Running an agent with full permissions is a local opt-in, off by default; a sender cannot ask for it.
• Your agents treat each other as teammates. Every paired device is in the top trust tier, owner: they are all yours. When you start a hand-off in one session, the request carries your authority to the next session, as if you had delegated it in person. The receiving agent keeps its judgment: it can push back, suggest a better approach, or ask before anything destructive or irreversible, but it won't refuse legitimate work just because the request came from another agent. (ADR-016)

Loop limits

Two agents replying to each other could burn tokens indefinitely. anytoany caps how many messages one thread can hold and how many it accepts per minute, and refuses further sends past either limit. Each message gives the receiver one turn; nothing keeps running unattended.

What anytoany does not protect against

• A stolen device key. Whoever has ~/.anytoany/identity/key.pem can act as that device until you run anyd pair remove on your other devices. Protect it like an SSH key; disk encryption helps.
• Reading the mailbox on disk. Messages are encrypted between devices, but stored as plain text in the local mailbox. Anyone who can read your home folder can read them.
• Software already running as you. The local API on 127.0.0.1 accepts any process running under your user account without a token; that is what lets a sandboxed desktop assistant use anytoany. A program running as you can therefore queue a message as any of your agents. The boundary is your user account, the same as for your shell history or SSH keys.
• Seeing your devices on the network. Bonjour announcements include each device's name and public ID, so others on the same network can see that they exist.
• Other people's devices. There is no restricted tier for a device or agent that isn't yours yet. A guest tier, where messages would carry no authority and consequential actions would need the receiving owner's approval, is designed but not implemented. Only pair devices you own.
• A compromised agent. If an attacker already controls one of your paired agents or machines, anytoany is not the last line of defense.

How this compares

Remote Control facts are from Anthropic's documentation as of 2026-10-27, which says All traffic travels through the Anthropic API over TLS and that the session transcript is stored on Anthropic's servers while connected: Remote Control, cross-session messaging. For Claude-to-Claude messages on the same machine, Claude Code uses a local socket and does not go through Anthropic. "Shared-token LAN pairing" is how anytoany itself worked before ADR-028. "Cloud-relayed" describes the general approach, not a particular product.

Reporting a vulnerability

Please don't open a public issue. Use GitHub's private vulnerability reporting. What counts as in scope is listed in SECURITY.md.

FAQ