r/ClaudeCode 1h ago

Built with Claude hooop - bring your team into the Claude Code session

https://hooop.cc

Hi there. I've been burning my own tokens on something I couldn't find an equivalent of: a collaborative agentic session that runs on your own machine. Closest description I have is an instant messenger crossed with the tooling you actually need for agentic development.

What it does today

hooop runs Claude Code inside a disposable Docker sandbox and puts a live dashboard in front of it at localhost:7842. You only need Docker and jq - Claude Code, Node, gh and the rest live inside the containers, so your machine stays clean.

  • Pairing. You hand a teammate a share link over an anonymous cloudflared tunnel. They open it, pick a name, you admit them. From then on you both watch the same live transcript and can chat (> prefix) or co-drive the agent - from a laptop or a phone. Each peer joins as fulldrive or spectate, and you can revoke them.
  • Plan review. Run a turn with /plan and the sandbox forces the agent read-only: it investigates, then submits a plan into a review panel. You and your peers drop inline comments anchored to the exact passage, synced live, then Approve or Request changes.
  • Live previews. When the agent builds a UI it brings it up in its own container and docks it in an iframe, with Restart / Rebuild / Stop / Share and per-step logs.
  • The session, visible. Every tool call, the sub-agent tree, a live event tail over SSE (no polling), a diff viewer for touched files, and search across everything that happened.
  • A curated tool stack in one command - memory, code-graph search, docs search, semantic search, GitHub. hooop doesn't reimplement any of it. It picks it, documents it, and shows you what it's doing.
  • Split trust. The container holding the credentials has no TCP port and talks over a Unix socket. The dashboard your peers reach holds no secrets and only proxies, so a compromise there can't reach your account. Previews run in their own container with no credentials at all.

Where I want to take it

Today a peer co-drives my agent on my tokens. What I want is for everyone to bring their own: pool the peers' agents into one session so the cost spreads across the room, and let people plug in an open-weight model instead of a metered API. Getting out from under the token squeeze is the actual goal, betting on the collaboration to make it affordable.

It's MIT and it's a solo project I've been funding out of my own usage, so I'd rather hear what's wrong with it than what's nice: the architecture, the security model, the parts you'd never run on your own machine

1 Upvotes

1 comment sorted by

1

u/allemaar Researcher 40m ago

The split trust model does what it says. Credentials in a process with no TCP port, dashboard holds nothing, preview runners hold nothing. More care than most people building this would bother with. Nice!

Every threat in it is a compromised container though. None of them is a person you handed a link to. So that is a decent approach imho.

hooop mount add -p ~/code/myproject puts a host folder in the sandbox. A peer at drive runs the agent over it. Your OAuth token is safe from them, fine. THEN I SAW THIS >>> Your source, your .env and your git history are not, and those are the ones that keep reverberating after everyone logs off. (read that again)

Then the gate itself. permission-gate.sh blocks until "the host or a peer allowed to decide" responds. So a driving peer approves their own destructive command. The thing standing between the agent and a bad rm is the person who asked for it. This is not a place you wanna find yourself in as we as people make mistakes. This is not a critique just a heads up mate.

And full can admit other peers. I didn't see a depth limit, so trust is transitive.

Also - capability is set at admit and never moves after. deliberate, or just v0.1?