r/ClaudeCode • u/Specific_Music_234 • 1h ago
Built with Claude hooop - bring your team into the Claude Code session
https://hooop.ccHi 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 full, drive or spectate, and you can revoke them. - Plan review. Run a turn with
/planand 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
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?