# Outreach Templates

---

## Template 1: Cold email to Claude Code / MCP team at Anthropic

**To:** jobs@anthropic.com
**Alt:** DM @davidsp (David Soria Parra, MCP lead) or @bcherny (Boris Cherny, Claude Code) on X

**Subject:** Built an E2E-encrypted mesh for Claude Code sessions — found some things about dev-channels

---

Hi,

I'm Alejandro Gutiérrez — fighter pilot turned AI builder. 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 ([THREAT_MODEL.md](https://github.com/alezmad/claudemesh-cli/blob/main/THREAT_MODEL.md)).

The repo is MIT: [github.com/alezmad/claudemesh-cli](https://github.com/alezmad/claudemesh-cli). Protocol spec: [PROTOCOL.md](https://github.com/alezmad/claudemesh-cli/blob/main/PROTOCOL.md).

Before software I spent a decade flying F-18s and running operational safety for the Spanish Air Force. The safety thinking transfers directly: systems either handle failure modes or they fail people. That's what drew me to Anthropic.

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.

Alejandro A. Gutiérrez Mourente
info@whyrating.com · linkedin.com/in/alejandrogutierrezmourente
claudemesh.com · github.com/alezmad/claudemesh-cli

---

## 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 @davidsp @bcherny — 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://github.com/alezmad/claudemesh-cli/blob/main/PROTOCOL.md
npm: claudemesh-cli

Would love feedback on the trust model and the protocol design.
```

---

*All templates drafted 2026-04-05. Personalized 2026-04-06. Verify all URLs are live before sending.*