Feature request: real-time multi-user collaboration on a single Claude Code session

[apstorenet]

Summary

There is currently no way for two different user accounts to share and collaborate on a single Claude Code session in real time (think Google Docs / VS Code Live Share, but for a Claude Code chat).

Current state (as I understand it)

• "Share" links from claude.ai are read-only views, not collaborative.
• "Teammates" and "peer sessions" all belong to the same account — different devices/processes, not different humans.
• Remote Control lets you drive your session from another device, but again — single user.
• The only workarounds are screen sharing (one person types) or tmux session sharing (not officially supported).

Use cases this would unlock

• Pair programming with a colleague where both can prompt the same agent.
• Mentoring / onboarding: a senior dev watches a junior's session live and can intervene.
• Live code review where reviewer and author both interact with Claude in the same context.
• Async handoff where a teammate picks up exactly where you left off (richer than a shared transcript).

Possible shapes

• A "Share session" action on claude.ai/code that grants edit access to another Anthropic account (with permission scopes: view / suggest / write).
• An equivalent of isolatePeerMachines extended to cross-account peers (with explicit per-message approval).
• Read-write share links with expiry, similar to Figma/Notion.

Why it matters

Claude Code is increasingly used inside teams, but the paradigm is still "single user + agentic delegation." For software work that is fundamentally collaborative, this is a gap that pushes teams to clunkier workarounds (screen sharing, copy-pasting transcripts).

Thanks for considering!

[stephengardner]

https://mobsession.ai is built for exactly this, and works with your Claude code subscription running on your computer

[prassanna-ravishankar]

the read-only-share-link limitation is the crux, watching isnt collaborating, and the mentoring case (senior watches a junior live and steps in) needs a way to actually intervene.

repowire has session sharing (a viewer link to a live session via a relay proxy) plus the mesh control layer, so the watcher can both see the session and steer it by sending into it, rather than only reading. it works across accounts since the share is token-based rather than tied to one account.

honest caveat: repowires sharing is watch + steer-over-mesh, not yet full google-docs-style multiple-cursors co-prompting in one transcript. so for live pair-programming with two people typing into the same session its not the complete answer, but for watch-live-and-intervene (the mentoring case) it covers it today.

[kcarriedo]

Hitting this from the orchestration side - the single-user constraint becomes most visible when you're running an overnight agent task and a teammate needs to nudge it or check its state without you.

A pattern that helps short-term: designate one "observer" session that only reads worktree files and posts short status notes to a shared scratch file the main agent watches. Not real collaboration, but it removes the "only the original user can intervene" bottleneck. The tmux-claude-session-manager plugin (github.com/craftzdog/tmux-claude-session-manager) helps with the "which session needs attention" part of the problem if you're on the same machine.

The deeper ask here - multiple humans with independent cursors in one session - seems like it needs a first-class server-side primitive. The share link being read-only is the gap. Watching this one.

[infiter4]

Hello, I think this is a really interesting issue and I've actually been working towards a solution for it, I've faced this myself as a young SWE working on a fairly large project with my colleagues but I want to make sure it's a real problem for more people than just me
The way I'm thinking of solving it at a base level is a wrapper over almost every existing coding tool (Codex, Claude Code, Manus etc) that gives you a session link anyone can drop into, with varying permission levels and shared sessions
I Would love any feedback on this, and if you've run into this yourself I'd really like to hear how it actually went for you, for more info drop me a DM on discord at aimbot_399 or just reply here and ill follow up even 5 minutes would help a lot

[tres-caras]

From an enterprise angle, +1. I'm a systems engineer at a large company, and the gap isn't only real-time collaboration on one session — it's that two people's separate Claude Code sessions have no first-class way to talk to each other. Today the only cross-session channels are a shared file both agents read/write, or the SendMessage/peer primitives that assume a single account. In a big org, work is handed off across people constantly, so a supported cross-session conversation channel (session A messages session B, gated by the other human's approval) would be as valuable as a shared live session — and fits async team workflows better. The proposed permission scopes (view/suggest/write) and per-message approval are exactly right.