collaborative multi-session Claude

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

In distributed software systems — industrial control systems, client/server applications, microservices — changes to shared interfaces require coordinated updates across multiple codebases owned by different developers. Today, this coordination is manual: it lives in someone's head, in a ticket, or in a Slack message that gets missed. The result is broken interfaces, integration bugs, and duplicated effort onboarding new team members.

Each developer's Claude session has deep context for their own code but is blind to what's happening on the other side of an interface. There is no mechanism for one session to inform another.

Proposed Solution

A hub-and-spoke session model that allows multiple developers to share a common project context through Claude, with ownership tracking, async change propagation, and cross-domain impact awareness — enabling Claude to act as both a coding assistant and a distributed systems coordinator across a team.

Allow Claude sessions to form a project — a named group of sessions sharing a common hub that maintains:

An ownership map (who owns which modules, files, or domains)
A registry of shared interfaces between owners
A history of cross-domain decisions and their rationale
An async work queue of pending proposals per developer

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

Currently, I'm working on an application that interfaces with multiple systems, each maintained by a different person. If I add a variable to the data structure that is being written to a PLC (Programmable logic controller, in this case an S7-400), the person who is working in the S7 code needs to know that this is added and why. For interfacing with the SQL database, I need to generate documentation or walk over to the guy who maintains the database and ask him to create a table or a column to an existing table and give me permissions.

In theory, if I make a change where I want to get a variable from the PLC and store it in a database, I could just do the work in the server using Claude, and, with this system Claude can inform the other two developers of what changes they will need to make, how to make them (if necessary) or do it for them in some cases (with their permission), and also maintain consistent documentation (where applicable).

Additional Context

Key behaviors
Interface inference — Claude infers shared interfaces from code on both sides (e.g. matching struct and PLC DB layout). The PM is prompted on setup to choose inferred or explicit declaration.
Change propagation — when a developer changes a shared interface, Claude drafts the corresponding change for the counterpart and queues it as a proposal.
Async work queue — proposals accumulate while a developer is away. On return, Claude presents a prioritized summary and lets them choose the order to catch up.
Configurable commit gating — per-interface setting: changes can be blocked until counterpart acknowledges, or advisory only.
Cross-system documentation — because the hub holds context for all participants, it can generate documentation accurate from both sides of any interface simultaneously, without either developer authoring it.
Decision history — rationale for interface design is preserved. Stored in code comments where practical, in a richer store otherwise. Any session can query why something was designed the way it was.
Flexible project scope — a project is whatever the PM declares. A two-machine caster control system, a microservices backend, or an entire mill. The system enforces contracts within whatever boundary is defined.
Why this matters
This shifts Claude from a per-developer coding assistant to a distributed systems coordinator. The artifact is not just working code — it is a living, queryable model of the entire system that any participant can interrogate, and that actively maintains consistency across domain boundaries.

The cross-system documentation benefit alone addresses a chronic pain point in distributed systems work: documentation written by one side is always incomplete from the other side's perspective. A hub with full context eliminates that gap without adding documentation burden to either developer.

There are related requests (#21277 and #28300) that are very similar to what I am proposing.