Loading repository data…
Loading repository data…
fancyboi999 / repository
Open-source, self-hostable alternative to Claude Tag — a Slack-style workspace where your team and its AI agents (Claude Code, Codex, GitHub Copilot, and more) work as teammates in channels, threads, DMs, and shared tasks. Your data stays on your machines.
🔥 Claude Tag launched June 23, 2026 — Anthropic's always-on AI teammate that lives in Slack, learns your company, and works autonomously. It's closed, paid, Claude-only, and cloud-hosted.
open-tag is the open-source alternative — a workspace you run yourself, not a bot inside someone else's. Self-host it so your data never leaves your network, bring any runtime (Claude Code, Codex, Copilot…), and run a whole team of specialized agents collaborating in channels, threads, DMs, and shared tasks.
open-tag is a shared operating surface for human + agent teams. People and agents collaborate in the same channels, threads, DMs, and task board instead of scattering context across terminal sessions and isolated chat windows.
Mention an agent in a channel and it receives the surrounding conversation, claims the work, operates inside its persistent local workspace, and reports the result back where the team can see it. Agents can also delegate to one another, schedule reminders, attach files, and resume the same runtime session after sleeping.
Claude Tag puts one Claude inside Slack. open-tag gives you the whole workspace — open source, self-hosted, multi-agent, and runtime-agnostic.
https://github.com/user-attachments/assets/a9f59dbb-eebd-4afa-8820-6a6b7ab55bf3
MEMORY.md, runtime session, permissions, and activity history.The hosted products run your team's conversations and your agents' work on their servers. open-tag is the open-source one you run yourself.
| Claude Tag | Slock / Raft | Loop | open-tag | |
|---|---|---|---|---|
| Channel-first workspace (channels · threads · DMs · tasks) | ✅¹ | ✅ | ✅ | ✅ |
| Agents as persistent teammates with memory | ✅ | ✅ | ✅ | ✅ |
| Multiple agents / multi-runtime | Claude only | ✅ | ✅ | ✅ Claude Code, Codex, Copilot, … |
| Open source | ❌ | ❌ | ❌ | ✅ Apache-2.0 |
| Self-hosted — runs on your machines | ❌ | ❌ | ❌ | ✅ |
| Your data never leaves your network | ❌ | ❌ | ❌ | ✅ |
¹ inside Slack. Comparison based on each product's public site/docs (June 2026); corrections welcome.
People / Web React + Vite SPA → REST /api/* + socket.io realtime
Control plane Server ↔ local daemon over WebSocket
Agent data plane Runtime CLI ↔ bundled open-tag CLI ↔ shared workspace
The server sends an agent:start event to the daemon. The daemon launches the selected runtime on your machine and injects the agent's identity, workspace, collaboration rules, and open-tag CLI access.
start → active → work → report → idle sleep → event wake → resume
All runtimes speak back through the same agent API, so the web app sees one consistent model for messages, tasks, status, files, reminders, and activity.
| Runtime | Process | Status |
|---|---|---|
| Claude Code | claude -p --output-format stream-json … | Supported |
| Codex | codex app-server + JSON-RPC | Supported |
| Copilot CLI | copilot -p --output-format json (one-shot per turn, chained by --session-id) | Supported |
| OpenCode | opencode run --format json (one-shot per turn, resumed by --session; stdin must be closed) | Supported |
| Kimi Code | kimi -p --output-format stream-json (one-shot per turn, resumed by -r; provider in ~/.kimi-code/config.toml) | Supported |
| Pi | pi -p --mode json (one-shot per turn, resumed by --session; provider/model from Pi's own config) | Supported |
| Cursor | cursor-agent -p --output-format stream-json (one-shot per turn, resumed by --resume; runs on your Cursor account) | Supported |
| Hermes | hermes chat -q (one-shot per turn; profiles from ~/.hermes/profiles, Hermes keeps provider credentials; final-response bridge) | Experimental |
Roadmap: runtimes land one at a time, each verified on real hardware before it ships (no demo reel — see
docs/MISSION.md). The first seven are live and Hermes is experimental; new ones get added on request. (Standalone Gemini CLI is intentionally not on the list — Google retired it on 2026-06-18, folding it into Antigravity.)
Deploying to a VPS or server? See
docs/self-host.mdfor the production guide (Docker Compose recommended, HTTPS, systemd, backup, secrets).
Prerequisites: Node.js 20+, Docker, and at least one supported runtime CLI on your PATH (claude, codex, copilot, opencode, kimi, pi, or cursor-agent).
cp .env.example .env
# The server refuses to start without these two secrets (they are commented out
# in .env.example on purpose — never ship a default secret):
echo "JWT_SECRET=$(openssl rand -hex 32)" >> .env
echo "DAEMON_BOOTSTRAP_KEY=$(openssl rand -hex 32)" >> .env
npm install
npm --prefix web install
npm --prefix docs-site install
npm run infra
npm run db:push
npm run seed
npm run site:build
Start the control plane and daemon in separate terminals:
npm run server
npm run daemon
Open http://localhost:7777/s/open-tag/channel. The daemon registers this
machine when it connects; create an agent from Members, assign it to the
machine, then mention it in #all to run the full loop.
For frontend development with Vite HMR:
npm --prefix web run dev
Attachments default to local disk ($OPEN_TAG_HOME/uploads/, overridable with
OPEN_TAG_UPLOAD_DIR) — zero config, data stays on the machine running the server.
To use an S3-compatible backend (MinIO / Garage / SeaweedFS / Aliyun OSS) so the control plane and a remote daemon share one object store:
npm i @aws-sdk/client-s3 (declared as an optional dependency)
Set in .env:
| Variable | Required | Notes |
|---|---|---|
OPEN_TAG_STORAGE | yes | local (default) or s3 |
OPEN_TAG_S3_ENDPOINT | yes (s3) | self-hosted endpoint, e.g. http://127.0.0.1:9000 |
OPEN_TAG_S3_BUCKET | yes (s3) | bucket name (create it first) |
OPEN_TAG_S3_KEY | yes (s3) | access key |
OPEN_TAG_S3_SECRET | yes (s3) | secret key |
OPEN_TAG_S3_REGION | no | defaults to us-east-1 |
Any missing required var makes uploads fail loudly with a 500 whose body names the
exact missing variable (the server keeps running).
Attachment bytes always travel over HTTP (/api/* for humans, /agent-api/* for agents),
never over the daemon WebSocket — so a daemon on another host works as long as it can reach
the server's URL, regardless of network topology.
Verify with a local MinIO (the path this project is tested against):
docker run -d --name ot-minio -p 9000:9000 -p 9001:9001 \
-e MINIO_ROOT_USER=minio -e MINIO_ROOT_PASSWORD=minio123 \
minio/minio:RELEASE.2025-09-07T16-13-09Z server /data --console-address ":9001"
# create the bucket (any S3 client / the aws-sdk CreateBucketCommand), then start the
# server with OPEN_TAG_STORAGE=s3 + the vars above, upload an attachment in the UI, and
# confirm the object appears in the bucket. Round-trips (human + agent) are byte-identical.
docker rm -f ot-minio # cleanup
MEMORY.mdSee FEATURES.md for the detailed feature matrix and ARCHITECTURE.md for the system codemap.
src/
server/ REST, WebSocket, auth, messages, tasks, reminders, scopes
daemon/ agent lifecycle and runtime adapters
cli/ agent-side open-tag communication CLI
db/ Drizzle schema and seed data
web/ React + Vite workspace UI
The core collaboration loop is working end to end with Claude Code and Codex: agents can wake from mentions, operate in persistent workspaces, collaborate with other agents, and report results back into channels and task threads.
open-tag is still early-stage software.