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

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

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.

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.

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

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.

Same need here. What I keep wanting is a guest slot in my own session.

I'm working on a module, a colleague is working on the same one, and I want to pull him into the session I already have open. He sees what's happening live. If I let him, he can type a prompt too, but it shows up on my side first and I decide whether it goes in. Everything still runs on my machine, my files, my permissions. He never executes anything.

The approval step matters more than it sounds. It's not about trust, it's that someone dropping a side question into the middle of a long task will wreck the thread. If I get to say yes/no/reword first, the session stays usable.

Right now the options are screen share (he can't scroll back or copy anything) or two separate sessions both rebuilding the same context.

Read-only guests alone would already help a lot.

Same problem here. Share links are read-only, and peer sessions only work inside a single account, so there's no real way to hand actual work to someone else.

We ended up building something for it: CoAligne syncs both the sessions and the files an agent produced across a team, so a teammate picks up the whole working state rather than a transcript to read. (Obviously biased since I work on it.)

Curious what people are doing in the meantime — has anyone found a handoff workflow they're actually happy with?

On the guest-slot half of this, a tested interim. Disclosure, I work on Pilot Protocol, which develops shell.online. shell claude starts Claude Code in a detached PTY and prints a link. A colleague opens it in any browser and is inside your session, watching live and typing if you shared the interactive link, or watching only with shell --read-only claude. It survives disconnects on both sides and dies when the session ends.

Honest limits for this thread's ask. It is one shared PTY under your account, not per-user identities, and the link is a bearer credential, treat it like a password. MIT, single Go binary, curl -fsSL https://shell.online/install | sh.

Pairing and mentoring between teammates is exactly what we are building toward, so if anyone here tries it for that, I want the blunt version of what is missing or wrong.

The same workaround was arrived at independently by the two commenters: in both cases a file was used which could be accessed and modified by both sessions. One refers to this as the only means of communication between sessions currently available, while the other describes setting up an observer session which records its status into a scratch file for the main agent to monitor.

It's worth identifying the failure mode of that workaround before any more of it is developed, since both sessions read the file, both write, and the second write quietly erases the first; no errors occur and the run appears normal, so it doesn't require real-time collaboration in order to cause a problem, only a handoff that takes place while the other side is still working.

The part of this concerning the conversation has to rely on Anthropic, but the workspace portion does not: when a session has mutated the files and objects, the restored member by member checkpoint consists of a live writer who brings the conclusion to a bounded conflict rather than a clobber.

When running it offline without using any keys, the baseline arm exhibits the loss first: python -m examples.workspace_versioning.main --baseline (github.com/Cohexa-ai/agent-coherence, I work on it).

I'm surprised many people already experienced this issue, and I'm not the only one. This need to be served by Claude, not other company. We are already using and learning Calude and use it in a commercial setting. If another company's solution offered this feature, we would have to sign a contract with them and go through a data gibberish processing workflow. And we don't want that.

@tres-caras @kcarriedo @nagualul @pyeonggwone I'm a student looking into, for a school project, what people actually do when they need another person inside their AI work, either at the same time or picking it up later. This thread has more real examples of that in one place than anywhere else I've found: an observer session reading status off a scratch file, a shared file as the only channel between two people's sessions, wanting a guest slot in a session you already have open, not wanting to sign a data agreement with a third party just to get this. I couldn't find another way to reach any of you from GitHub. If any of you would be open to a short call about how this actually comes up in your work, I'm at oluwaniifemi.emmanuel@uni.minerva.edu, and a couple of lines here would help just as much.

Disclosure: I work on Bottari, so this isn't a neutral recommendation.

We hit all four of your use cases ourselves and built Bottari for them: different accounts, different humans, one Claude Code session, in real time.

Pair programming, live code review, mentoring. A teammate opens the session you already have running and prompts the same agent — nothing to re-explain, because the context is the session rather than something you hand over. The other direction works too: you open their session and watch it run.

Async handoff. Reassign the session and the next person picks up where you left off, on their machine, under their own Claude login, with the reasoning intact rather than a transcript.

Permission scopes — your view / suggest / write. Ours are view, comment, edit and full, and a session defaults to comment for the space. A comment lands in the session for the owner to act on but never reaches the model, so a commenter can't make your agent do anything. Edit is granted per person, deliberately, because that teammate's turns then open on the owner's machine, against the owner's files and permissions.

Explicit per-message approval. We don't have that gate. Instead you branch a thread off the specific reply in question and pull in whoever you need; that thread runs while the main task keeps going, so a side question doesn't land in the middle of a long run.

Read-write share links with expiry. This one is coming soon — it's already on the way. Today links open in the Bottari app and entering a session needs a team invite; expiring read-write links are next.

If you try it, I'd like the blunt version of what's missing.

https://bottari.ai

Disclosure: I'm Rob, and I built this, so not a neutral take.

Your "view / suggest / write" scopes are close to how I ended up doing it in Bellows, a desktop app (Windows, macOS, Linux) that runs Claude and other agents. You share a running session with a link, and the link carries one role: watch, suggest or type. A suggestion goes into a queue on the host and only reaches the agent if the host accepts it, which covers the "explicit per-message approval" shape. Answering permission prompts is a separate switch, off by default. The guest needs only a browser, no account.

Limits worth knowing before you try it:

• It isn't a share button on an existing Claude Code terminal session. You run the agent inside Bellows, and Claude there uses an API key (or a provider), not a claude.ai subscription login.
• On the same network the app serves the guest page itself, free. Across networks it goes through a relay that forwards end-to-end encrypted frames; that part is on the paid Team plan.

40-second clip of a guest joining and suggesting a change: https://bellowsai.app/#demo
How it works: https://bellowsai.app/guides/share-a-coding-agent-session-live?utm_source=github&utm_medium=reply

Agree this ought to exist natively, though.

— Rob