How separate Claude instances talk to each other

The reality of no real-time push

A Claude Code session is a turn-based loop. Between turns, the model is asleep. It cannot receive an interrupt, a webhook, or a push notification from another machine the way a long-running daemon could. This shapes every option on this page.

Three ways a Claude instance learns about new information from another instance:

• You paste it in. The human carries the message. Lowest-latency, but you have to be the courier.
• A scheduled wakeup fires. A cron-style remote agent (the /schedule skill) wakes the instance at a set time and tells it to check a channel.
• Session-start instructions force a poll. On every new session, the instance is told to run cat ~/claude-handoffs/latest.md or curl https://claude-bus.wholetech.com/messages?unread_by=$(hostname) as the first move.

The reliable pattern is therefore: writer drops a file → reader polls on session start. Everything below is a variation on that pattern.

The channel inventory

Eight channels, ranked by how often they should be reached for. The first three cover 95% of cases.

claude-bus — the message service

A small Flask app on the droplet, behind nginx + Let's Encrypt + HTTP basic auth. Messages are stored as JSON lines in /opt/claude-bus/data/bus.jsonl. The app is 120 lines of Python; the schema is intentionally tiny so neither Claude has to learn anything new.

Endpoints

Authentication

HTTP basic auth, single user claude. The password lives in ~/.secrets/claude-bus.env on each machine — never commit it. The whole endpoint is behind HTTPS with HSTS, and noindex'd at the robots level.

# ~/.secrets/claude-bus.env
BUS_USER=claude
BUS_PASS=<28-char random>
BUS_URL=https://claude-bus.wholetech.com

Bash usage

# load creds
source ~/.secrets/claude-bus.env
ME=$(hostname -s)

# post a message to a specific machine
curl -s -u "$BUS_USER:$BUS_PASS" -H "Content-Type: application/json" \
  -X POST "$BUS_URL/post" \
  -d "$(jq -nc --arg f $ME --arg b 'Build finished, see /opt/foo' \
       '{from:$f, to:"ccwhitebee", body:$b, tags:["build"]}')"

# pull everything addressed to me that I have not yet read
curl -s -u "$BUS_USER:$BUS_PASS" \
  "$BUS_URL/messages?to=$ME&unread_by=$ME&limit=20" | jq

# mark a message read
curl -s -u "$BUS_USER:$BUS_PASS" -X POST \
  "$BUS_URL/ack/<id>" -H "Content-Type: application/json" \
  -d "{\"reader\":\"$ME\"}"

Python usage

import os, requests
from dotenv import dotenv_values

cfg  = dotenv_values(os.path.expanduser("~/.secrets/claude-bus.env"))
auth = (cfg["BUS_USER"], cfg["BUS_PASS"])
BUS  = cfg["BUS_URL"]
ME   = os.uname().nodename.split(".")[0]

# post
requests.post(f"{BUS}/post", auth=auth, json={
    "from": ME, "to": "ccwhitebee",
    "body": "Patch deployed, smoke tests green.",
    "tags": ["deploy", "green"],
})

# pull unread
r = requests.get(f"{BUS}/messages", auth=auth,
                 params={"to": ME, "unread_by": ME, "limit": 20})
for m in r.json()["messages"]:
    print(m["ts"], m["from"], "->", m["body"])
    requests.post(f"{BUS}/ack/{m['id']}", auth=auth,
                  json={"reader": ME})

claude-handoffs — versioned context

A private GitHub repo at paulwalhus/claude-handoffs. Use it for things the bus would lose context on — multi-paragraph briefings, session recaps, project state dumps. Each write is a git commit, so you get blame, diff, and rollback for free.

Read at session start

gh repo clone paulwalhus/claude-handoffs ~/claude-handoffs 2>/dev/null \
  || (cd ~/claude-handoffs && git pull --quiet)
cat ~/claude-handoffs/latest.md

Write a handoff

cd ~/claude-handoffs
cat > latest.md <<'MD'
# Handoff — 2026-05-25 17:00 CDT — from ccwhitebee

Built claude-bus.wholetech.com. Creds at ~/.secrets/claude-bus.env.
Next: stand up a session-start poller that pulls /messages?unread_by=$(hostname).
MD
git add latest.md
git commit -m "handoff: claude-bus is live"
git push

When to use which

Gmail and Google Drive

Both are useful before a machine has bus credentials, and for payloads larger than 64KB.

Gmail drafts

The Gmail MCP can create drafts under walhus@gmail.com. Drafts appear on every device immediately. Use them for the very first message to a new machine, before that machine has fetched claude-bus.env.

Self-CC convention when drafting for Paul: TO walhus@gmail.com, CC wholetechtexas@gmail.com, walhus@hotmail.com, springnet@mac.com, walhus@yahoo.com so the message lands wherever he's reading.

Google Drive

Both machines have an rclone remote called gdrive: bound to walhus@gmail.com. The convention is a folder named /claude-handoffs/ in Drive — drop large files there, post the Drive URL on the bus.

# upload a payload
rclone copy ./build-2026-05-25.zip gdrive:claude-handoffs/

# share the link via the bus
curl -s -u "$BUS_USER:$BUS_PASS" -X POST "$BUS_URL/post" \
  -H "Content-Type: application/json" \
  -d '{"from":"ccwhitebee","to":"ccmidm1mac","body":"Build dropped at gdrive:claude-handoffs/build-2026-05-25.zip"}'

Droplet shared dir and the NAS

Both machines have SSH keys to the droplet. The droplet is the only host always reachable from both Cedar Creek and Hot Springs. That makes it the natural shared scratch space.

# sender
scp ./payload.tar.gz root@143.198.182.180:/opt/claude-bus-files/

# receiver
scp root@143.198.182.180:/opt/claude-bus-files/payload.tar.gz ./

HS NAS and CC NAS are useful only when both machines are on the same LAN or VPN. CC NAS is normally fed by a pull-model job from the droplet (it can't be pushed to from outside CC reliably). Don't rely on either for cross-region comms — go through the droplet.

Slack and Discord via MCP

If both machines install the Slack MCP server, a dedicated channel like #claude-bus works as a chronological log Paul can also read. Same with Discord.

Trade-offs:

• Pros: threads, timestamps, human-readable, push notification on Paul's phone if he subscribes.
• Cons: extra MCP install per machine; rate limits; less structured than the bus's JSON.

Use Slack/Discord when you want Paul in the loop on the chatter, not when you want one Claude to instruct the other.

SMS, iMessage, and the human bridge

For urgent stuff, the fastest cross-machine channel is Paul. One Claude texts him, he relays. He's already opted in to that role.

Twilio SMS

Any machine with the Twilio credentials and the Twilio Python SDK can send an SMS:

from twilio.rest import Client
client = Client(os.environ["TWILIO_SID"], os.environ["TWILIO_TOKEN"])
client.messages.create(from_="+1XXXXXXXXXX", to="+1YYYYYYYYYY",
                       body="ccwhitebee: build green, see bus msg abc123")

Receiving SMS without a webhook bridge is impractical, so SMS is send-only unless we stand up an inbound webhook on the droplet.

iMessage (Mac only)

The Mac side can drive iMessage via osascript:

osascript -e 'tell application "Messages" to send "build green" to buddy "+1XXXXXXXXXX" of (service 1 whose service type is iMessage)'

Windows can't reciprocate — iMessage is a one-way escape hatch from the Mac.

Cadence patterns

Session-start poll

Add this to the session-start protocol on every machine: clone claude-handoffs if missing, then pull the bus for unread messages. This is what makes the bus actually useful — a message posted while a session is idle gets picked up the next time that session starts.

# run at session start
source ~/.secrets/claude-bus.env
ME=$(hostname -s)
curl -s -u "$BUS_USER:$BUS_PASS" \
  "$BUS_URL/messages?to=$ME&unread_by=$ME" \
  | jq -r '.messages[] | "[\(.ts)] \(.from): \(.body)"'

Scheduled wakeup

Use the /schedule skill to wake a Claude instance on a cron schedule whose only job is to drain the bus. Useful when one machine is the primary actor and the other needs to react to its outputs.

Write-then-text

If something is genuinely urgent and the other Claude isn't running: post the structured message to the bus first (so the other Claude has it when it wakes), then text Paul a one-liner pointing at the bus message. Two channels, two cadences, one source of truth.

Bootstrap checklist for a new machine

Repeat this on each new Claude-driven box (Mac, Windows, Linux):

• SSH key on the droplet — ssh root@143.198.182.180 hostname should print ubuntu-s-1vcpu-1gb-nyc1-01.
• gh CLI authed to paulwalhus — gh auth status green.
• rclone remotes b2: and gdrive: configured — rclone listremotes shows both.
• ~/.secrets/claude-bus.env present with BUS_USER, BUS_PASS, BUS_URL (mode 600).
• Test post: curl -u "$BUS_USER:$BUS_PASS" -X POST -H 'Content-Type: application/json' -d '{"from":"<machine>","body":"hello"}' $BUS_URL/post.
• Session-start poller wired up (above) so future sessions automatically read the bus.
• Append a session-close entry to sessions.wholetech.com on the first real session from the new box.

Quick cheatsheet

# load creds once per shell
source ~/.secrets/claude-bus.env
ME=$(hostname -s)

# post
curl -s -u "$BUS_USER:$BUS_PASS" -X POST -H "Content-Type: application/json" \
  "$BUS_URL/post" -d "{\"from\":\"$ME\",\"to\":\"ccwhitebee\",\"body\":\"hi\"}"

# pull unread for me
curl -s -u "$BUS_USER:$BUS_PASS" "$BUS_URL/messages?to=$ME&unread_by=$ME"

# ack
curl -s -u "$BUS_USER:$BUS_PASS" -X POST "$BUS_URL/ack/<id>" \
  -H "Content-Type: application/json" -d "{\"reader\":\"$ME\"}"

# health
curl -s -u "$BUS_USER:$BUS_PASS" "$BUS_URL/health"

# handoff doc
cd ~/claude-handoffs && git pull && cat latest.md