[FEATURE] Cross Session Messaging for Multi Project Coordination

Preflight Checklist

• [x] I have searched existing feature requests and this is not a duplicate
• [x] This is a single feature request (not multiple bundled together)

Problem Statement

When working on interdependent projects across multiple terminals (e.g., a library in Terminal A and a consuming app in Terminal B), there is no way for Claude Code sessions to communicate with each other. This creates a broken workflow:

1. Terminal B discovers a bug or missing feature in the dependency managed by Terminal A
2. The user has to manually context switch, copy paste the issue details, and relay information between sessions
3. Terminal A fixes the issue and publishes a new version, but Terminal B has no way to know this happened
4. The user again manually relays "new version is out, you can continue now"

This is common in monorepos, microservice architectures, and any project with local dependencies under active development. The human becomes a message router between two AI agents that could coordinate directly.

This is essentially Agent to Agent (A2A) messaging at the CLI session level, a pattern gaining traction across the AI tooling ecosystem but not yet available in Claude Code.

Proposed Solution

A messaging system that allows Claude Code instances to send and receive messages to/from other running sessions. The ideal UX:

Sending a message (from Terminal B):

> The auth library is missing a `refreshToken` method. Notify the auth-lib session to add it.

Claude Code in Terminal B sends a structured message to Terminal A's session, then optionally waits or continues other work.

Receiving a message (in Terminal A):

[Incoming message from session "app-frontend"]
Request: Add `refreshToken` method to AuthClient. Needed for token rotation flow.

Claude Code in Terminal A processes the request, implements the fix, publishes, and sends a reply.

Reply back (from Terminal A to Terminal B):

[Incoming message from session "auth-lib"]
Done: `refreshToken` added in v2.3.1. Published to registry.

Key capabilities needed

• Session discovery: List and name running Claude Code sessions (e.g., claude --session-name auth-lib)
• Send message: Push a structured message (text + optional metadata like file paths, error logs) to another session
• Receive message: Surface incoming messages as interruptible notifications or queued items
• Reply/acknowledge: Close the loop so the originating session knows the work is done
• Wait/continue: Option to block until a reply comes back, or continue working on other tasks

Possible implementation approaches

• Local IPC (Unix domain sockets, named pipes) for same machine sessions
• A lightweight message broker (file based or in memory) that sessions register with
• Integration with the existing session/conversation infrastructure

Priority

High

Feature Category

CLI commands and flags

Alternative Solutions

Currently the only workaround is:

• Manually copy pasting context between terminals
• Using external tools (Slack, notes) to relay information
• Running everything in a single mega session (which loses the benefit of focused, project scoped contexts)

None of these scale well when the dependency chain is deep or changes are frequent.

Use Case Examples

1. Full stack app with a shared component library

1. User opens Terminal A: claude --session-name ui-components in /projects/ui-components
2. User opens Terminal B: claude --session-name dashboard-app in /projects/dashboard-app
3. While working in Terminal B, Claude discovers that <DataGrid> from ui-components has a sorting bug
4. Terminal B sends a message to the ui-components session: "DataGrid column sorting breaks when column type is 'date'. Comparator treats dates as strings."
5. Terminal A receives the message, investigates, fixes the bug, bumps version to 1.4.2, publishes
6. Terminal A replies to Terminal B: "Fixed in v1.4.2. DataGrid date sorting now uses proper date comparison."
7. Terminal B receives the reply, updates the dependency to 1.4.2, and continues the dashboard work

2. Microservice development

1. Terminal A works on the auth-service, Terminal B works on api-gateway
2. Terminal B needs a new endpoint from auth-service for token introspection
3. Terminal B messages Terminal A: "Need a POST /introspect endpoint that validates and returns token claims"
4. Terminal A implements the endpoint, deploys locally, replies with the contract
5. Terminal B integrates against the new endpoint and continues

3. Monorepo with build dependencies

1. Terminal A works on a shared utils package, Terminal B works on the web-app that depends on it
2. Terminal B hits a type error caused by a recent change in utils
3. Terminal B messages Terminal A with the type error and stack trace
4. Terminal A fixes the type, rebuilds, replies with confirmation
5. Terminal B picks up the fix and moves forward

The entire flow happens with minimal human intervention. The user oversees and approves actions but does not have to be the message carrier.

Additional Context

• This is distinct from existing "shared context" requests (#30675, #35721) which focus on sharing context between different products (Code vs Cowork vs Claude.ai). This is specifically about runtime communication between multiple CLI sessions.
• The cowork feature handles parallelism within a single project. This addresses coordination across projects.
• Security consideration: messaging should be scoped to the same user and machine by default, with explicit opt in for any broader communication.
• Could integrate with the hooks system: an on_message_received hook would let users customize how incoming messages are handled.
• Aligns with the broader A2A (Agent to Agent) communication patterns emerging in multi agent systems.