[FEATURE] Native cross-instance communication between separate Claude Code sessions
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
I'm building one product that spans two repositories in two different IDEs: ESP32
firmware (VSCode) and an Android app (Android Studio). Each repo runs its own Claude
Code session.
The two agents constantly need to agree on a shared contract: BLE/JSON message formats,
an OTA update flow, field names, telemetry schema, and firmware version compatibility.
When one side changes the protocol, the other must learn about it precisely.
Today there is no way for the two Claude Code sessions to talk to each other. I (the
human) am the message bus: I copy questions and answers between the two sessions by hand.
This is slow, error-prone, and doesn't scale beyond two projects. The agents can't ask
each other a direct question or confirm a schema change without me relaying every word.
Proposed Solution
A first-class way for two or more independent Claude Code instances — running in
different applications/repos on the same machine (or account) — to message each other
directly.
Ideal experience:
- A shared, named "channel" / mailbox that multiple Claude Code sessions can opt into
(e.g. claude --channel volvo-dpf or a per-channel setting).
- Agent-to-agent send/receive: one session can post a question or a structured artifact
and the other receives it as context and can reply, without the human copy-pasting.
- Carries structured payloads (JSON schemas, version contracts, field maps), not just
free text, so protocol agreements are machine-checkable on both ends.
- Permissioned and auditable: the human sees and approves what crosses between projects
(a diff/approval prompt before a message is delivered to the other repo), so secrets or
unrelated context don't leak between codebases.
Alternative Solutions
Current workaround: the two agents exchange hand-written markdown files in a shared
folder — one session writes QUESTIONS.md, the other writes ANSWERS.md, and I manually
copy file paths back and forth between the two IDEs. It works but I am literally the
message bus; every round-trip needs me.
Considered:
- A custom MCP server acting as a shared mailbox between the two sessions — feasible but
it's a non-trivial thing to build/maintain just for cross-agent chat, and it isn't an
out-of-the-box experience.
- Subagents: they coordinate within a single session, not across two separate Claude Code
instances in different applications.
Priority
High - Significant impact on productivity
Feature Category
Other
Use Case Example
Example scenario:
- I'm building ESP32 firmware (VSCode) and its companion Android app (Android Studio),
each with its own Claude Code session.
- The firmware agent adds a new BLE telemetry field and a self-update (OTA) command, and
changes the JSON message framing.
- With this feature, the firmware agent posts the updated schema + OTA protocol to a
shared channel; the Android agent receives it directly, asks two clarifying questions
back ("is reassembly by newline now mandatory?", "what are the error codes?"), and gets
structured answers — all without me relaying anything.
- Both sides converge on the exact same contract immediately. Today this took ~6 rounds
of me copying QUESTIONS.md / ANSWERS.md between two IDEs over several messages.
Additional Context
Real project where this came up: a firmware repo and an Android app repo that share a
BLE/JSON protocol and a GitHub-release-based OTA flow. We ended up creating a series of
files (QUESTIONS_R2.md, ANSWERS_R2.md, OTA_PROPOSAL.md, ...) purely to let the two agents
negotiate the protocol through me. A native channel would have removed the human as the
bottleneck while keeping me in control of what's shared.
Keeping it permissioned is important: I want to approve what context/secrets cross from
one repo to the other, not have them share everything automatically.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗