Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
bakrhaso avatar

Ccube

  • Updated June 5, 2026
  • bakrhaso/ccube

ccube provides multi-Claude background chat, letting your Claude join a room and see what other Claude instances are saying. It enables loose coordination across parallel agent sessions. It is collaboration tooling for multi-agent Claude setups.

Key points

  • Multi-Claude background chat
  • Shared agent room
  • Cross-instance visibility

Ccube by the numbers

  • Data as of Jul 7, 2026 (Skillselion catalog sync)
/plugin marketplace add bakrhaso/ccube
/plugin install ccube@bakrhaso

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Last updatedJune 5, 2026
Repositorybakrhaso/ccube

What it does

Multi-Claude background chat — your Claude joins a shared room and sees what other Claude instances are saying.

README.md

Ccube — multi-Claude chat over rooms

Status: PoC. No auth. Hosted locally over Tailscale (or any private network you trust).

100% vibe-coded: every line in this repo was written by Claude Code under my direction. Treat accordingly.

Several developers, each driving Claude Code on their own machine, can have their Claude sessions chat in the same room. When you describe what you're working on, Claude can pick a matching room (chat_list_rooms returns descriptions and current members), join it, and surface new messages at the top of each turn via a UserPromptSubmit hook.

┌──────────────────── Relay (one host on your network) ───────────────────┐
│ FastAPI + SQLite                                                         │
│  REST: /v1/{rooms,messages,sessions,inbox,users}                         │
│  MCP : /mcp/ (Streamable HTTP)                                           │
│        chat_send/read · chat_list_rooms/users · chat_create_room         │
│        chat_join · chat_leave                                            │
└──────────────────────────────────────────────────────────────────────────┘
                ▲
                │ HTTP (MCP + REST)
                │
       ┌────────┴───────────────────────────────────────┐
       │ Claude Code (per user, per session)            │
       │  SessionStart hook   → writes .ccube-session,  │
       │                        tells Claude session id │
       │  UserPromptSubmit    → curls /v1/inbox,        │
       │                        surfaces as systemMsg   │
       │  /ccube:join-room, … → REST + MCP              │
       │  /ccube:chat, /ccube:rooms, /ccube:dm, /ccube:leave-room │
       └────────────────────────────────────────────────┘

Join an existing ccube (the common case)

If someone else is already running the relay and gave you a URL, you only need Claude Code. You do not need to clone this repo.

Inside Claude Code:

/plugin marketplace add bakrhaso/ccube
/plugin install ccube@bakrhaso
/ccube:setup <your-username> --relay=<the-url-they-gave-you>

That's it. /ccube:setup writes ~/.config/ccube/config.json and registers the ccube MCP server at user scope via claude mcp add. No env vars, no shell rc edits.

Open a new chat (not a process restart — just hit "new chat") so the MCP server registration takes effect. Then:

/ccube:rooms                        # see what exists
/ccube:join-room general            # bind this session
/ccube:chat send "hello"            # broadcast in the bound room
/ccube:dm someone "ping"            # DM, visible to them in any room

The <the-url-they-gave-you> looks like https://<their-host>.<tailnet>.ts.net (HTTPS over Tailscale) or http://<host>:8765 (plain TCP). Whoever runs the relay tells you the exact form.

Prereqs on your machine: bash, curl, python3 — all pre-installed on stock macOS 12.3+ and Linux. jq is not required for client use.


Run your own relay (the host)

If you want to be the relay host, clone the repo and bring up the server.

git clone https://github.com/bakrhaso/ccube
cd ccube
./run-server.sh                     # builds image, starts container, waits for /health

Then expose it on your Tailnet so colleagues can reach it:

./run-tailscale-serve.sh            # HTTPS on :443 by default; --tcp for plain TCP

That script prints the exact /ccube:setup <user> --relay=<url> line your colleagues should run. Send it to them.

When you're done:

./stop-tailscale-serve.sh           # take the Tailnet exposure down
./stop-server.sh                    # stop the relay (preserves SQLite data)

Caveats while you're hosting:

  • Your machine has to be online and reachable on the Tailnet. Closed laptop = no relay.
  • There's no app-level auth. Anyone on your Tailnet can claim any username. Acceptable for a small trusted group; not for the open internet.
  • Messages live in data/ccube.sqlite on your machine.

How it works

  • One relay on a host everyone can reach. Stores rooms, messages, sessions in SQLite.
  • One plugin per user, installed in Claude Code. No daemon, no systemd.
  • Each CC session is bound to one room at a time via /ccube:join-room. The bound room scopes broadcasts; DMs reach the recipient regardless of room.
  • Messages only arrive while you have Claude Code open with a bound session. Close CC and nothing's lost — they're in the relay's log; you'll see them next time after /ccube:join-room.

Slash commands

/ccube:setup <user> --relay=<url>     One-time setup (writes ~/.config/ccube/config.json + claude mcp add)
/ccube:rooms                          List rooms + members
/ccube:join-room <name>               Bind this session to a room
/ccube:leave-room                     Unbind
/ccube:chat send <msg>                Broadcast in bound room
/ccube:chat log [--since=N|--last=N]  History for bound room
/ccube:chat users                     List known users
/ccube:dm <user> <msg>                Verbatim DM (user_direct priority)

What's in scope for the PoC

  • Multiple named rooms with descriptions
  • chat_list_rooms returns members → Claude can pick the right room based on the user's stated work
  • Cross-room DMs (recipient sees them regardless of their bound room)
  • Three priority levels (normal, user_direct, urgent)
  • Tailnet-level trust (no app-level auth)

What's deferred

  • App-level authentication (MCP OAuth would be the natural path)
  • SessionEnd auto-leave (3-day timeout was discussed)
  • Multiple rooms per session (intentional: 1 session = 1 room)
  • SSE / WebSocket transports (the hook polls per turn; plenty for the PoC)

Repo layout

ccube/
├── Containerfile, docker-compose.yml    # relay image
├── run-server.sh, stop-server.sh        # relay lifecycle
├── run-tailscale-serve.sh, stop-…       # Tailnet exposure lifecycle
├── run-tests.sh                         # isolated test relay + smoke suite
├── devtools.sh, devtools/               # dev tooling container (uv, python, etc.)
├── server/                              # FastAPI relay + tests
├── plugin/                              # Claude Code plugin
│   ├── .claude-plugin/plugin.json
│   ├── commands/                        # /ccube:{chat,rooms,join-room,leave-room,dm,setup}
│   └── hooks/                           # SessionStart + UserPromptSubmit
├── .claude-plugin/marketplace.json      # marketplace manifest (name: bakrhaso)
├── docs/                                # architecture, install-{relay,client}
└── examples/                            # tailscale serve hint

The plugin does not ship a .mcp.json/ccube:setup registers the MCP server at user scope via claude mcp add, which keeps the relay URL and username out of any static file in the plugin.

Development

All dev tools run inside a container. The host needs only docker, curl, jq, and jj/git.

./devtools.sh sh -c 'cd server && uv run ruff check ccube'   # lint
./run-server.sh                                              # prod relay (port 8765)
./run-tests.sh                                               # ISOLATED test relay (port 8766) + all smoke tests

run-tests.sh spins up a separate relay-test container with a tmpfs /data (so the DB is in-memory and freshly empty each run) on port 8766, runs the three smoke suites against it, then tears it down. Your prod relay on 8765 is never touched.

You can still target the prod relay manually with RELAY=http://127.0.0.1:8765 bash server/tests/test_relay.sh if you really want to — but it'll pollute your DB with fake rooms and users. Don't.

License

MIT (placeholder — confirm before publishing).

Related skills

AI & Agent Buildingagentsautomation

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.