RClaude

Talk to one Claude. Together.


Context / History / Why We Built This

Open a group chat with your friends right now. Go ahead! Somewhere in there is a coding project three of you swore you'd finish this weekend, and a message that says "wait can you send me your screen again." Don't laugh — you do this on every single hackathon.

Here's the thing nobody says out loud: Claude Code is genuinely incredible, and it is also completely, aggressively single-player. One person, one terminal, one chat. Your teammate sitting right next to you cannot see what you're asking, can't jump in, can't correct the prompt while it's running. So what do people actually do? They screen-share. They read prompts out loud like it's 1997. They paste Claude's answers into Slack. Or the classic — one person "drives" for four hours while everyone else watches like it's a Twitch stream (0% contribution rate lmao).

And the "collaborative" coding tools? They collaborate on the editor. Everybody's cursor wiggling around a Google-Doc-for-code while the actual AI doing the work is still locked inside one person's laptop. They solved the wrong half of the problem.

In other words: the smartest teammate in the room can only be rented by one human at a time.

So we asked: what if Claude Code was a room your whole team could walk into — talk to the same Claude, see the same code, and have it all just stay in sync, with no git ceremony?


What It Does

RClaude turns Claude Code from a single-player terminal into a shared room your whole team lives in.

No, this isn't:

  • Screen-sharing your terminal and reading prompts out loud
  • Pasting Claude's replies into Slack one message at a time
  • A shared text editor with a dumb autocomplete bolted on
  • Everyone waiting for the one person with "the good API key"

What we built is dead simple: you spin up a room, your teammates join, and everyone chats with one Claude — every message attributed to who said it. Claude sees the whole conversation as one team talking to it, not four disconnected sessions. And the code stays in sync automatically, live, with zero git push / git pull — you edit a file by hand, they see it; Claude edits a file, everyone sees it.

The twist nobody expects: turns execute on the sender's machine. Whoever hits enter runs that turn on their own key, on their own box. No central host, no "who's paying for this," no single point of failure. The room is shared; the compute is yours.


Our Favorite Part of RClaude

Picture this. You're in a room with two teammates. You type "refactor the auth module." It runs on your laptop, your key. Your teammate watches Claude's tool calls stream in live — reading files, making edits — rendered on their screen frame-for-frame as if they typed it themselves. The files Claude touches show up in their working directory seconds later. No pull. No merge. It's just there.

Then they type "now add tests for it" — and that turn runs on their machine, against the exact same session, same history, same code. Claude doesn't even know it changed hands. One brain, one conversation, one codebase — three humans, three machines, one Claude. Imagine that.

And when you're done? Walk right back into real Claude Code and your whole history is sitting there, intact. It writes back to ~/.claude like nothing happened.


How We Built It

A standalone CLI built on the Claude Agent SDK, with an Ink TUI that clones the real Claude Code interface 1:1 — same colors, same rhythm, same feel. Multiplayer runs over a WebSocket relay (ws + SQLite) that carries three things: attributed chat, the single-writer turn lock, and live code sync.

Sync is git-shadow-driven — PostToolUse/Stop hooks snapshot changes into a per-room bare repo and fan them back out, so it works even on repos with no git, skips your .gitignore and giant files, and does last-writer-wins with a parked copy + notify on collisions. Remote turns render by replaying the executor's own reducer actions over the wire, so everyone sees the identical stream. API-key auth only — because it's the only thing that's actually allowed.


Challenges We Ran Into

Sessions are chaos when you share them. The SDK persists real Claude-Code-format session logs itself, and getting one stable session ID that survives being resumed, mirrored, and handed between machines — without duplicating the entire history on every turn — took genuinely careful plumbing.

Ink fought us too: pasted input arrives as one newline-terminated chunk that looks exactly like pressing enter; a startup race left a single frame with the wrong input focus, so fast typing landed in the wrong box.

And our testing was pty scripts driving an ANSI-heavy TUI — where the terminal's own escape codes split words apart mid-pattern, two fast keystrokes silently merged into one message, and an orphaned relay from a crashed test kept serving stale state while we lost an hour blaming our own code.


What We Learned

Separating the shared conversation from where the work runs was the whole unlock. The room is a shared surface; the compute stays with whoever spoke. That one decision made billing fair (everyone pays for their own turns), removed the central host as a bottleneck and a liability, and made the thing scale sideways for free.

And treating session interop as a hard rule — you must be able to walk back into real Claude Code with your history intact — forced an honesty on the architecture that made everything else cleaner: RClaude is a room you visit, not a place you get trapped.


What's Next for RClaude

  • Relay-side lock timeouts so a wedged turn can never freeze a room
  • Richer collision UX than parked-copy-and-notify
  • Cross-machine presence and cursors
  • Packaged one-command install
  • Public beta

Built With

Share this project:

Updates