Inter-Session Agent Communication for Claude Code

Resolved 💬 2 comments Opened Jun 18, 2026 by jaymoj Closed Jun 19, 2026

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

When developing features that span multiple codebases (e.g., iOS client + backend services), teams often run separate Claude Code sessions for each domain:

Session A: iOS/Swift development

Session B: Backend/Go development

Current workflow when cross-domain questions arise:

Client agent identifies a question (e.g., "Does the backend support idempotent requests?")

Client agent asks the developer to clarify with the backend team

Developer Slacks the backend team: "Client agent is asking..."

Backend developer asks cloud agent to investigate

Cloud agent investigates uncommitted code and responds

Backend developer Slacks the answer back

Client developer shares response with client agent

Client agent continues work

This 7-step human-relay process creates bottlenecks:

❌ Context switching for developers

❌ Async delays (waiting for Slack responses)

❌ Increased coordination overhead as teams scale

❌ Loss of investigation details in translation

❌ Not suitable for real-time collaboration

Proposed Solution

Desired Solution

Enable agents in separate Claude Code sessions to communicate asynchronously, allowing:

Client agent → asks question → Cloud agent

Cloud agent investigates uncommitted code

Cloud agent → responds → Client agent

Developers stay in their respective sessions

Optimized workflow:

Client agent encounters question about backend API

Client agent sends async request to cloud session: "Does subscription API support idempotent requests?"

Cloud agent receives request, investigates code

Cloud agent responds with detailed answer

Client agent continues work with answer

Developer involvement: minimal

Alternative Solutions

Alternative/Interim Solutions (if full feature isn't feasible)

Currently I am doing these steps. It reduces some copy pasting. But, still human intervention is there.

Shared .claude/DECISIONS.md file — Both agents read/write decisions (low-effort workaround)

API contract documentation — Upfront spec reduces back-and-forth (current workaround)

At the minimum if this can be done the agents get better context. But, context sharing is expensive. With Anthropic's limited context lengths, this may be unusable or bad user experience, but still it would work:

Session context sharing — Allow exporting/importing context between sessions

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

Use Case: Logue AI

Context:

Building a voice transcription and audio processing product (iOS + Go backend)

Currently implementing subscription payment feature (Stripe integration)

Parallel development: iOS team + Backend team

Code not committed yet (in-progress feature development)

Need rapid feedback loops between teams

Example scenario:

Client agent: "I need to generate an idempotency key for subscription
creation. What format does the backend API expect?"

Cloud agent (investigating backend code): "The API accepts any UUID v4
string in the Idempotency-Key header. Stripe uses this
to deduplicate requests. Backend stores it in Redis for
60 seconds. Here's the relevant code..."

Client agent: "Perfect, I'll use Foundation's UUID(). Does the auth
header need to be Bearer or Basic?"

Cloud agent: "Bearer. Here's the exact format from the code..."

This reduces developer context switches from 7 steps to 0.

Additional Context

Proposed API / Implementation

Option A: CLI-based async requests

In client session, run a command

claude --send-request cloud-session "Does the subscription API support idempotent requests?"

In cloud session, receive and respond

[AGENT_REQUEST from client-session]:
"Does the subscription API support idempotent requests?"

[Cloud agent investigates and responds] Your response will be sent back to client-session.

Option B: Via .claude/peers.txt or session registry

.claude/peers.txt (in both projects)

backend_session: "meetnotes/src/cloud"
client_session: "meetnotes/src/ios"

Then:

claude --ask-peer backend_session "question about API"

Option C: Shared session workspace

claude --workspace logue-feature-subscription

Both agents can connect to the same workspace

Separate conversation threads per domain

Shared file access for both

Technical Requirements

Session discovery — Agents can reference other sessions by ID or project path

Async messaging — Requests don't block; responses arrive when ready

Context isolation — Each agent's codebase/context remains private unless explicitly shared

Timeout handling — Graceful failure if peer session is inactive

Message history — Record of all inter-session questions/answers for debugging

Code visibility control — Cloud agent can see cloud code but not client code (unless file is explicitly shared)

Impact

Developer Productivity

Reduces context-switching overhead

Eliminates async Slack communication for technical questions

Speeds up cross-team feature development

Code Quality

Agents can investigate actual code instead of relying on developer descriptions

Fewer misunderstandings between teams

Permanent record of decisions

Scalability

Enables teams of any size to develop in parallel

Works for any multi-codebase architecture: Monorepo with multiple services

Separate repos with interdependencies

Mobile + Backend + Infrastructure code

Claude Code Competitive Advantage

Other tools (GitHub Copilot, Cursor) don't support multi-agent coordination

This would be a unique differentiator for teams using Claude Code

Governance & Security

Session Pairing (Explicit Configuration)

To prevent unauthorized communication, sessions should be explicitly paired during setup:

In client project root

.claude/peers.txt
---
name: iOS Client
session_id: logue-client-ios
can_request_from: logue-backend-cloud
can_respond_to: logue-backend-cloud

In backend project root

.claude/peers.txt
---
name: Backend Cloud
session_id: logue-backend-cloud
can_request_from: logue-client-ios
can_respond_to: logue-client-ios

Benefits:

✅ Explicit governance (only approved pairs communicate)

✅ Security (no random sessions can send requests)

✅ Audit trail (who talked to whom)

✅ Team scalability (can add logue-backend-python, logue-infra sessions)

Message Scope

Requests should be Q&A only; agents can't execute code on behalf of peers:

✅ "What does the subscription API return for error case X?"

❌ "Write code to implement feature Y"

❌ "Modify the backend repo"

Approval Flow (Optional)

For enterprises, could add approval gates:

Developer A asks: "Can cloud agent answer this?"
Cloud agent responds (with optional: requires developer approval?)

This is infrastructure-level; core feature doesn't need it initially.

Non-Requirements

Real-time editing: Just async Q&A

Code merging: Each agent stays in their session

Full codebase access: Cloud agent still can't read iOS code (unless shared)

Video/voice: Text-based is fine

Complex approval workflows: Simple allow/deny is sufficient for MVP

Success Metrics

If implemented, success would be measured by:

Developer time spent in agent-to-agent coordination loops

Number of Slack messages between teams during feature development

Feature velocity for cross-domain features

Conclusion

This feature would unlock Claude Code as the tool for coordinated multi-team development, especially for companies building products that span multiple platforms/services (mobile + backend, frontend + API, etc.).

For Logue AI specifically, this would reduce feature development time by eliminating the 5-7 step human relay for every technical question that crosses team boundaries.

Is this something Anthropic is already considering? I'm happy to be an early beta tester or provide more detailed requirements.

My contact information:
Jay Mojnidar
Founder Data Lingo Solutions
jay@datalingosolutions.com

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗