Communicating between Claudes

The six primitives

Inter-Claude communication isn't one thing — it's six. Each handles a different question, and most real fleets use four or five of them at once. Recognising which primitive each request is asking for is half the work.

The first three are active — one Claude reaches out and does something on another machine. The last three are passive — they exist as infrastructure that multiple Claudes (and humans) draw from.

SSH + claude exec

The simplest inter-Claude primitive. SSH to a remote host, run claude exec (or codex exec for the other agent), get the result back. Same model you've used for decades to run anything else on a remote box — Claude is just another command.

The one-liner

# from your laptop, run a one-shot Claude task on the droplet
$ ssh root@wholetech.com "cd /var/www/codex.wholetech.com && claude --print 'summarise the recent commits in this site repo'"

That's the whole thing. The flag is --print (or the older alias -p) — it tells Claude Code to run non-interactively, print the answer, and exit. The remote host needs to have Claude Code installed and authenticated.

Authenticating Claude on a server you'll SSH into

Server boxes don't have a browser, so the usual claude login OAuth flow doesn't work directly. Three options:

1. API key. Set ANTHROPIC_API_KEY in the server's environment (or /etc/environment for system-wide). The CLI picks it up automatically. Cleanest for a server.
2. Headless OAuth. claude login --no-browser prints a URL; open it on a laptop, paste the resulting code back. One-time.
3. Copy ~/.claude/auth.json from a logged-in machine. Works but ties the server's identity to a specific browser session — refresh tokens expire, and you've duplicated a sensitive credential.

Patterns that pay off

Piping data in

Anything you pipe into claude -p becomes the input. Useful for sending another command's output through Claude before printing.

$ ssh root@wholetech.com "journalctl -u nginx --since yesterday | claude -p 'find the request patterns that look like scrapers'"

The inbox pattern

Where remote invocation is "do this now, return the answer," a shared queue is "drop this on a list; whoever's free will pick it up." It decouples the producer from the consumer in time. Useful when the work is bursty, when the machine doing the work isn't always on, or when you want a record of what was asked.

The simplest queue: a directory

Pick a shared location — NAS mount, a directory on the droplet, a synced OneDrive folder. Each task is a file. The producer writes a file; a consumer picks it up, runs Claude, writes the result alongside.

/mnt/queue/
  pending/
    2026-05-18T14:22-summarise-pr-1234.md     # input prompt
    2026-05-18T14:25-bump-tailwind-v4.md
  running/
    2026-05-18T14:01-investigate-cron-fail.md.host-droplet
  done/
    2026-05-18T13:42-find-unused-deps.md
    2026-05-18T13:42-find-unused-deps.md.result

The worker loop

One Claude per host runs a tiny loop. Pull a file from pending/, move to running/ (atomically, with a hostname suffix so two workers don't grab the same one), run Claude on the contents, write the result to done/.

#!/usr/bin/env bash
# queue-worker.sh — minimal, idempotent, runs on any host
set -euo pipefail
QUEUE="/mnt/queue"
HOST="$(hostname -s)"

while true; do
  # atomic claim: find one pending, mv to running with our host suffix
  for f in "$QUEUE/pending"/*.md; do
    [[ -e "$f" ]] || continue
    target="$QUEUE/running/$(basename "$f").host-$HOST"
    if mv -n "$f" "$target" 2>/dev/null; then
      # we won the race — run it
      claude --print < "$target" > "${target}.result"
      mv "$target" "$QUEUE/done/$(basename "$target" .host-$HOST)"
      mv "${target}.result" "$QUEUE/done/"
    fi
  done
  sleep 5
done

Where it wins

• Work that lands while you're asleep. Drop a task at 22:00; the droplet picks it up overnight; the result is waiting at 08:00.
• Two-phase tasks. A laptop generates a list of repos to audit; the droplet (which has stronger network) does the actual git clone + scan; the laptop reads back the summaries.
• Audit trail. Every task is a file. Six months later, you can see what was asked, what was answered, who did it.

Where it doesn't

• Interactive work. Latency between drop and result is by design loose.
• Anything that needs follow-up turns. The queue model is one-shot. For multi-turn use remote invocation or a managed agent.

Let one Claude reach into another box

MCP (Model Context Protocol) lets Claude call tools that aren't built in — filesystem access, GitHub, Postgres, custom services. By default the MCP server runs as a local subprocess on the same machine as Claude. But MCP also speaks over network transports: SSE and stdio-over-SSH. That means Claude on PC A can invoke MCP tools that run on PC B.

Three transports

Pattern: filesystem MCP on the droplet, called from your laptop

Your laptop runs Claude. You want Claude to read live files from /var/www/ on the droplet. Configure an MCP server in ~/.claude/settings.json that runs over SSH:

"mcpServers": {
  "droplet-www": {
    "command": "ssh",
    "args": [
      "root@wholetech.com",
      "npx -y @modelcontextprotocol/server-filesystem /var/www"
    ]
  }
}

Now Claude on the laptop can list, read, and (with permission) write files inside /var/www/ on the droplet, as if they were local — but every tool call routes through the SSH tunnel to the remote process. The remote MCP server speaks stdio; SSH bridges stdio across the network.

Pattern: a long-lived MCP service on the droplet

For something heavier — say, a database connection pool or a connector that takes 10 seconds to warm up — you don't want a fresh subprocess per session. Run the MCP server as a systemd unit on the droplet, exposed on a local socket, and have Claude connect via the SSE transport over an SSH-forwarded port.

// on the droplet: systemd unit running an MCP HTTP server on 127.0.0.1:3050
// from the laptop: forward the port
$ ssh -fNL 3050:127.0.0.1:3050 root@wholetech.com

// settings.json on the laptop
"mcpServers": {
  "droplet-postgres": {
    "transport": "sse",
    "url": "http://localhost:3050/mcp"
  }
}

Pattern: exposing the WholeTech network from one Claude

The high-leverage move for a multi-machine setup: run a small MCP server on the droplet that exposes "tools" representing the rest of your network — sitemap data, nginx config snippets, scheduled-task status. Now any Claude that mounts this server can ask questions about the whole fleet without having to SSH to each box.

Telling you what the Claudes did

Half of inter-Claude communication is the Claudes talking to each other. The other half is the network telling you when something happened. Three transports, each with a different lag and a different reach.

$ curl -d "droplet cron finished — 247 changes in today's sitemap" https://ntfy.sh/walhus-claude

$ curl -s "https://api.pushover.net/1/messages.json" \
    -F "token=$PUSHOVER_TOKEN" -F "user=$PUSHOVER_USER" \
    -F "message=Claude on droplet just touched nginx" \
    -F "priority=1"

$ curl -X POST -H 'Content-Type: application/json' \
    -d '{"text":"droplet Claude: cert renewal succeeded for codex.wholetech.com"}' \
    https://hooks.slack.com/services/T.../B.../...

The routing pattern that actually works

Set a single environment variable on every machine — CLAUDE_NOTIFY_URL — pointing at one of the three transports above. Every Claude on every machine fires its Stop hook against that one URL. Now you have:

1. One notification channel for "Claude finished a task somewhere in the fleet."
2. Per-machine differentiation (the hook posts $(hostname) in the message body).
3. Easy switch between transports — change the env var, redeploy, every machine routes to the new place.

# in ~/.claude/settings.json on every machine
"hooks": {
  "Stop": [{
    "matcher": "",
    "hooks": [{
      "type": "command",
      "command": "curl -s -d \"[$HOSTNAME] claude finished\" $CLAUDE_NOTIFY_URL"
    }]
  }]
}

Cloud Claudes that run while you're away

Anthropic's Managed Agents (sometimes called "agent SDK in the cloud" or referenced via /managed-agents) are persistent Claude sessions running in Anthropic's infrastructure. You kick one off; it spins up a fresh container with your repo cloned; it works for hours; you check back. From a fleet perspective they're "another Claude, but the host is the cloud."

When to reach for managed agents over your own boxes

The communication bit

From the fleet's point of view a managed agent is reachable in three ways:

• Web UI — claude.ai/agents (or whatever the current URL is). You see the agent's progress, comment, redirect.
• GitHub. Mention @claude in a comment; that's a managed agent picking it up.
• API / SDK. Kick off agents programmatically from a local Claude. The local Claude can read the agent's status, poll for completion, ingest the result.

Threads that follow you

The other primitive that hides in plain sight: claude.ai threads themselves act as persistent state across machines. Start a conversation on your phone walking to lunch; sit down at the laptop; the same thread is there in your browser. This isn't "communication between Claudes" in the agent-to-agent sense, but it's the most-used form of it in practice.

What syncs

The split that matters: claude.ai-family surfaces (web, mobile apps, managed agents) all share threads. Claude Code sessions are independent — they don't appear in your claude.ai history. That's an intentional separation: CLI sessions touch your local filesystem, where threads are noisier; cloud surfaces are about the conversation itself.

Cross-surface hand-off patterns

The primary orchestrator

Once you have three or more Claudes and a couple of these primitives, the question becomes "who's in charge." The cleanest answer for a small fleet is to pick one machine as the orchestrator — the place where decisions happen and tasks fan out from — and treat the others as workers.

The shape

What the orchestrator owns

• The decision. What needs doing, and which other machine is the best home for it.
• The collation. When multiple workers finish, the orchestrator collects their outputs and synthesises.
• The audit log. Every dispatch lands in one log file on the orchestrator.
• The notifications. Workers ping the orchestrator; the orchestrator (or a separate notify service) pings you.

What the workers own

• Their machine's reality. The droplet knows about nginx, certbot, /var/www/. The NAS knows about the backups. Mobile knows about voice and the camera. Each worker is the expert on its local surface.
• Idempotency. Re-running the same task should produce the same result. The orchestrator may retry.

Why this beats a mesh

A mesh — every Claude talks to every other Claude — sounds elegant but produces hard-to-debug behaviour. Two Claudes both edit the same file. Two notifications fire for the same event. Pick a primary, route through it. If the orchestrator dies, you promote a worker. /settings/architecture goes deeper on this.

Three real multi-Claude flows

Flow 1 — "The deploy pipeline"

1. Laptop Claude (CLI). Edits files in C:\Users\walhu\websites\codex.wholetech.com\. Runs /diff, eyeballs.
2. Laptop Claude. Calls scp to push the new index.html to the droplet. Then ssh root@wholetech.com 'claude -p "scan the new /var/www/codex.wholetech.com/index.html for any external URLs that 404"'.
3. Droplet Claude (remote invocation). Reads the file, fans out curl -sI on each link, reports back.
4. Laptop Claude. Receives the report, decides if anything needs fixing.
5. Stop hook (on laptop). Fires curl ntfy.sh/walhus-claude. Phone buzzes "deploy clean."

Flow 2 — "The overnight batch"

1. Friday 17:00, laptop. Drops 10 task files in /mnt/queue/pending/ via the NAS mount. Each one is a small refactor of a different site in the WholeTech network.
2. Droplet queue worker. Picks tasks up over the weekend. For each: runs claude --print < task.md, commits the result to a feature branch, opens a GitHub PR.
3. Managed agent. Each PR also kicks off an automated review agent (@claude review). The agent comments inline on any concerns.
4. Monday 09:00. Laptop Claude reads the 10 PR results, ranks them by which need human review vs which can auto-merge, posts a summary to Slack.

Flow 3 — "The mobile-initiated investigation"

1. iOS Claude. You photograph a confusing graph in Grafana while standing in front of a TV. Ask voice: "what's the most likely cause of this spike at 14:00."
2. iOS Claude. Suggests three hypotheses. You pick one: "yeah, can we dig into the nginx log?"
3. iOS Claude. Doesn't have SSH. So you walk to the laptop, open claude.ai on the browser — the same thread is there, still in voice mode's transcript.
4. Laptop CLI Claude. You quote the hypothesis into a fresh CLI session. It runs ssh root@wholetech.com 'journalctl -u nginx --since 13:30 --until 14:30 | claude -p "find requests matching pattern X"'.
5. Droplet Claude. Returns the actual log evidence. Laptop CLI synthesises an answer.
6. Stop hook. ntfy notification. You confirm the hypothesis was right.

Three Claudes, three transports, one investigation. None of the individual pieces are hard; the value is the choreography.

Knowing what each Claude did

A fleet without logging is a fleet you can't trust. Three logging layers, each catching different things.

# minimal logging wrapper around remote invocation
function ssh-claude {
  local host="$1"; shift
  local msg="$*"
  echo "$(date -Iseconds)  dispatch  host=$host  msg=$msg" >> ~/.claude/fleet.log
  ssh "$host" "claude --print" <<< "$msg" | tee -a ~/.claude/fleet.log
}

Inter-Claude trust boundaries

Every primitive above moves data, instructions, or credentials between machines. Each one needs a moment of thought about who can do what to whom.

SSH key hygiene for the fleet

• One key per machine, not one shared key. If the laptop is stolen, you revoke that key on the droplet — not "rotate the key on every machine."
• Use ed25519 keys. Smaller, faster, modern. ssh-keygen -t ed25519 -C "laptop@wholetech-fleet".
• Authorize with restrictions where you can. In ~/.ssh/authorized_keys on the droplet: command="/usr/local/bin/claude-runner",no-agent-forwarding,no-port-forwarding ssh-ed25519 AAAA... to lock the key to a single wrapper script.
• Use SSH config aliases. Your ~/.ssh/config defines Host droplet → HostName wholetech.com, User root, IdentityFile ~/.ssh/wholetech. Now everything in this guide uses ssh droplet instead of ssh root@wholetech.com, which means rotating a key is editing one file.

What goes wrong

The rest of the hub