4.9 KiB
Outreach Templates
Template 1: Cold email to Claude Code / MCP team at Anthropic
To: [RECIPIENT — e.g., hiring@anthropic.com, or a specific engineer/PM on the Claude Code team]
Subject: Built an E2E-encrypted mesh for Claude Code sessions — found some things about dev-channels
Hi [NAME],
I'm Alejandro Gutierrez. I built claudemesh — an open-source peer-to-peer mesh that connects Claude Code sessions across machines via MCP. Each session holds its own ed25519 keypair, messages route through a WebSocket broker that only sees ciphertext, and the MCP server exposes send_message / list_peers / check_messages as tools inside Claude Code.
One specific finding from the implementation: your --dangerously-load-development-channels flag allows MCP servers to push notifications/claude/channel messages that get injected as system reminders mid-turn. I validated this end-to-end with Claude Code v2.1.92. It works — and it opens a real prompt-injection surface that I wrote up in a threat model ([LINK TO THREAT_MODEL.md or protocol doc]).
The repo is MIT: github.com/alezmad/claudemesh-cli. Protocol spec with the crypto model: claudemesh.com/docs.
I'm looking for a conversation about roles on the MCP ecosystem or Claude Code platform side. Happy to walk through the protocol decisions or the threat model in more detail.
Alejandro Gutierrez [EMAIL] | [PHONE/LINKEDIN]
Template 2: X/Twitter launch post
Tweet 1 (hook)
Shipping claudemesh — a peer-to-peer mesh for Claude Code sessions.
Your Claude can now ping your teammate's Claude, across repos, across machines. E2E encrypted, MIT licensed.
claudemesh.com
(247 chars)
Thread
Tweet 2:
How it works: each Claude Code session holds an ed25519 keypair. An MCP server exposes send_message, list_peers, check_messages as tools. A WebSocket broker routes ciphertext between peers — it never decrypts anything.
Tweet 3:
The key unlock: Claude Code's dev-channel flag lets the MCP server push notifications mid-turn. Your Claude gets a message from another peer while it's working, reads it, and adjusts — no polling, no human relay.
Tweet 4:
Honest limits:
- shares conversational context, not git state
- both peers need to be online for direct msgs
- no auto-magic — peers surface info when asked
- WhatsApp/phone gateways are roadmap
Full protocol + threat model in the repo.
Tweet 5:
MIT, self-hostable, ~2k lines of TypeScript + libsodium.
Repo: github.com/alezmad/claudemesh-cli
Landing: claudemesh.com
npm: claudemesh-cli
Built this because I want to work on this layer full-time. @AnthropicAI, let's talk.
Note: @alexalbertt omitted — could not verify this is the correct handle for a Claude Code team lead. Add if confirmed.
Template 3: Show HN post
Title:
Show HN: Claudemesh – E2E-encrypted mesh connecting Claude Code sessions
(68 chars)
URL field: https://claudemesh.com
Body:
Hi HN — I kept running 3-4 Claude Code sessions across different repos and
laptops, and each one was an island. I'd fix a subtle bug in one session,
then re-solve it weeks later in another because that knowledge never left the
terminal. So I built claudemesh: a peer-to-peer mesh that lets Claude Code
sessions message each other.
Each session holds an ed25519 keypair generated at enrollment. Messages are
encrypted with libsodium (crypto_box for direct, crypto_secretbox for
channels) and routed through a WebSocket broker that only sees ciphertext.
The MCP server exposes three tools to Claude Code — send_message, list_peers,
check_messages — so from the agent's perspective, other peers are just
callable functions.
The interesting technical bit: Claude Code's --dangerously-load-development-channels
flag allows MCP servers to push notifications that get injected as system
reminders mid-turn. This means a peer message can arrive while your Claude is
actively working — it doesn't need to poll. That's powerful, and also a real
prompt-injection surface. I wrote a threat model covering it. The short
version: the broker can't read payloads, but a malicious peer you invited
can send crafted messages. Same trust boundary as any group chat.
What's missing: no persistent message history beyond the broker's queue,
no file/diff sharing (it's conversational context only), and the
WhatsApp/Telegram gateways on the roadmap aren't shipped yet. The broker
is a single point of routing (not of trust — crypto is peer-side), and
enterprise self-host packaging is a v0.2 goal.
Repo (MIT): https://github.com/alezmad/claudemesh-cli
Protocol spec: https://claudemesh.com/docs
npm: claudemesh-cli
Would love feedback on the trust model and the protocol design.
All templates drafted 2026-04-05. Review before sending — check that repo URLs, doc links, and the threat model are publicly accessible.