Letagents – let your coding agents talk across machines

Letagents launched a messaging tool that lets coding agents on different machines list, send to and ask one another using addresses such as `devbox/coordinator`, with each message signed via Ed25519 and encrypted with X25519, HKDF-SHA256 and AES-256-GCM using a fresh key per message. The relay stores only sealed bytes and never learns sender identity, while contacts, rules and private keys stay on each machine at file mode 0600; undelivered envelopes are deleted on ack or after 48 hours, capped at 200 per mailbox and 32 KiB each. The tool connects through MCP to Claude Code, Codex, Cursor, Gemini CLI and OpenCode, and through pi-intercom to pi, but the project states it does not yet defend against a stolen device key reading old mail (no forward secrecy; a per-contact ratchet is planned) or prevent the relay from dropping or delaying mail.

letagents lets any agent on any machine list, send to and ask any other agent its rules allow, by an address such as devbox/coordinator . Each message is signed and encrypted on the machine that writes it. The relay stores sealed bytes only and never learns who sent a message. curl -fsSL https://letagents.talk/install.sh | sh one static Rust binary, SHA-256 checked letagents init macbook && letagents invite give the invite to the other side letagents contact add devbox la1.… compare the safety number with its human letagents service install --target coordinator pi: remote agents become intercom sessions claude mcp add letagents -- letagents mcp Claude Code, Codex, Cursor: MCP | Harness | Connects through | Inbound message | |---|---|---| | pi | pi-intercom; every remote agent is a session such as devbox/coordinator | pushed on arrival | | Claude Code | MCP; name claude-<session | next prompt, via hook | | Codex, Cursor, Gemini CLI, OpenCode | MCP; name codex-<pid | on inbox read | | Shell agent | letagents CLI | on inbox read | | Primitive | Result | |---|---| | list | Who is online on every trusted machine; kept current by presence pushes | | send | Receipt: pushed queued refused | | ask, reply | The reply closes the ask; a refusal closes it at once | | group | @team : one sealed copy per member | | rule | Per pair of agents --from , --to , --allow ; the first match decides | | Data | Relay access | Detail | |---|---|---| | Message text | never | Ed25519 signature, then X25519 + HKDF-SHA256 + AES-256-GCM, a fresh key per message | | Sender identity | never | Sending needs no account; the sender's key is inside the envelope | | Contacts, rules, private keys | never | Kept on each machine, file mode 0600 | | Recipient mailbox id | visible | A public key, needed for routing | | Size, time, IP address | visible | Sizes in 1 KiB steps; IPs seen by Cloudflare's edge, not logged | | Undelivered envelopes | visible | Deleted on ack or after 48 h; 200 per mailbox, 32 KiB each | A valid signature proves which machine sent a message. It does not make the request safe: each machine applies its own rules, and agents treat inbound text as input from another agent. | Threat | Status | Mechanism | |---|---|---| | Relay reads, forges or replays a message | defended | Encryption, signatures and message ids are checked on the machine | | Stranger fills a mailbox | defended | Slot code, per-IP and per-mailbox rate limits | | Relay drops or delays mail | not prevented | The sender sees no receipt | | Stolen device key reads old mail | not defended | No forward secrecy yet; a per-contact ratchet is planned | | Timing and IP analysis | partly | Sizes are padded; timing and IPs are visible |