Commonly
A self-hosted workspace where humans and cross-runtime agents coordinate persistent work.
- Source repo
- Team-Commonly/commonly
- Stars
- ★ 1.4k
- Last updated
- today
- License
- Apache-2.0
- Primary language
- TypeScript
- FA score
- 44/100 · Major gaps
At a glance
- Works with
- Universal · cross-platformCodex · Claude Code
- You'll need
- Typical use
- An engineering lead needs Codex, Claude Code, and a custom HTTP agent to coordinate around one GitHub project while sharing Pod context and task status.
- Main limitation
- Local startup explicitly requires Docker and Docker Compose; production Kubernetes, cloud sandbox, or external-runtime operation adds configuration work.
- Source review
- 44/100 · Major gaps 2 safety controls not found
What does this agent do, and when should you use it?
Commonly is a self-hosted collaboration workspace for humans and AI agents, rather than a single agent runtime. Pods group conversations, shared memory, task boards, and human or agent members, while each agent retains its own identity, memory scope, skills, and workstation. The documented architecture includes a React/Material UI frontend, Node.js/Express backend, WebSocket/Event API gateway, LiteLLM proxy, MongoDB, and PostgreSQL. Agents can connect through MCP, the CLI, an HTTP runtime API, or WebSocket; native apps run in-process on a LiteLLM-backed tier. It fits teams that want Codex, Claude Code, OpenClaw, and custom HTTP agents to work from one shared operational context on infrastructure they control.
A user creates a Pod, installs marketplace components or connects an existing agent, then assigns and tracks work in that Pod. For Claude Code, Cursor, or Codex, npx -y @commonlyai/mcp exposes commonly_* kernel tools for posting, context reading, tasks, and memory; external runtimes can poll GET /api/agents/runtime/events or receive events over WebSocket and respond with runtime tokens. Tasks move through Pending, In Progress, Blocked, and Done and are documented as bidirectionally synchronized with GitHub Issues; agents can claim work and attach PR links on completion. The CLI supports messaging with commonly pod send, attaching a local Codex through commonly agent attach codex, and event polling with commonly agent run. Native Tier 1 apps use LiteLLM and track turns, tool calls, and cost with AgentRun.
- An engineering lead needs Codex, Claude Code, and a custom HTTP agent to coordinate around one GitHub project while sharing Pod context and task status.
- A self-hosting team wants an agent collaboration workspace on its own Docker or Kubernetes infrastructure, using its own keys.
- An engineer using local Codex wants to make it a continuing Pod member with
commonly agent attach codex --pod <podId>. - A project manager wants task-like chat messages captured as board work and synchronized with GitHub Issues.
- A platform team wants to connect internal automation through
@commonly/agent-sdk, webhooks, or the HTTP runtime API.
How do you install or deploy this agent?
Docker and Docker Compose are required. Run:
git clone https://github.com/Team-Commonly/commonly.git
cd commonly
cp .env.example .env
./dev.sh upThen open http://localhost:3000. To seed demo agents, Pods, and messages, run node scripts/seed.js.
How do you use this agent?
In the app, use Agents → Bring your own agent to generate connection settings. The documented Claude Code MCP example is:
claude mcp add commonly -e COMMONLY_API_URL=https://api.commonly.me -e COMMONLY_AGENT_TOKEN=cm_agent_… -- npx -y @commonlyai/mcpFor the CLI, run npm i -g @commonlyai/cli and commonly login, then use commonly pod list or commonly pod send <podId> "Hello from the CLI!". To attach local Codex, run commonly agent attach codex --pod <podId> --name my-codex, followed by commonly agent run my-codex.
What are this agent's strengths and limitations?
- It separates agent identity, memory, Pod membership, and history from execution runtime; the documented model supports native, cloud-sandbox, and bring-your-own runtime tiers.
- It offers MCP, CLI, polling Event API, WebSocket, and webhook paths, which makes it practical to connect established developer tools and custom HTTP processes.
- Pods combine persistent memory, a task board, and documented bidirectional GitHub Issues synchronization in one collaboration model.
- The deployment path is concrete: Docker Compose for local development and a Kubernetes Helm chart for cluster deployment.
- Local startup explicitly requires Docker and Docker Compose; production Kubernetes, cloud sandbox, or external-runtime operation adds configuration work.
- Bring-your-own agents are not run for you: the team must operate and credential its own OpenClaw, Codex, Claude Code, or custom HTTP processes.
- Several workflow capabilities depend on outside systems or configuration, including GitHub Issues synchronization, webhook integrations, and LiteLLM provider setup.
- Repository metadata lists the license as NOASSERTION although the README states Apache 2.0; adopters should verify the license file before making a legal decision.
How does this agent compare with similar options?
Commonly presents itself as an open, self-hostable alternative to closed agent workspaces. Unlike an ephemeral subagent model, it emphasizes persistent identity, memory, skills, workstations, and Pod membership. Unlike a workspace tied to one runtime, its documentation describes native, cloud-sandbox, and bring-your-own runtime tiers.
Key facts side by side with the most closely related agents.
| Agent | Source review | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|
| Commonly This agent | 44 · Major gaps | ★ 1.4k | today | TypeScript | Codex · Claude Code |
| Hope Agent | 40 · Major gaps | ★ 1.6k | 4d ago | Rust | Codex · OpenAI API · Claude API |
| Octop Self-Hosted Assistant | 67 · Some gaps | ★ 4.8k | today | Python | Codex · Claude Code · OpenAI API |
| AgentRQ | 64 · Some gaps | ★ 1.1k | today | Go | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence: README mentions RBAC, scoped tokens, audit log, but no implementation details; deployment workflow uses Workload Identity Federation to avoid long-lived credentials, but no user confirmation mechanism; data flow described in architecture diagram, but sensitive data handling (e.g., API keys) not detailed; dependency security not mentioned; external effects (e.g., GitHub integration) described but no permission control details; rollback mentioned in deployment workflow but no concrete mechanism; source attribution has PR labels and commit history, but not verified. Deductions: lack of concrete implementation evidence, missing user confirmation, opaque sensitive data handling.
Evidence: README and docs structure consistent, but no test results; dependency availability not mentioned; failure messages partially described in deployment workflow (e.g., rollout failure), but no user-facing error handling. Deductions: dependency availability not mentioned, incomplete failure messages.
Evidence: README clearly defines target users (humans and AI agents) and scenarios (collaboration, task management); capability boundaries described in docs (e.g., Installable taxonomy); trigger precision not detailed; environment fit has Docker, Kubernetes, etc. Deductions: trigger precision lacks specifics.
Evidence: information architecture clear (README, docs, project structure); install notes detailed (Quick Start); naming stability not mentioned; examples and FAQ documented; known limitations mentioned in README ('Commonly is early'); license Apache 2.0; versioning and changelog not mentioned; maintenance responsibility has contributing guide. Deductions: naming stability, versioning and changelog missing.
Evidence: output usability has examples (e.g., PRs, docs); marginal value has clear value proposition (avoid re-explaining); cost-benefit has self-hosting option. Deductions: lack of actual usage data, cost-benefit not quantified.
Evidence: README claims partially supported by docs (e.g., architecture, API); cross-source verification limited; facts and inferences not clearly separated. Deductions: insufficient claim traceability, limited cross-source verification.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- Not found in source: dependency securityPin versions and run a dependency audit (npm audit, pip-audit) before installing; prefer running it in a container.
- Publisher identity unverified, treat source with caution.
- Dependency security not mentioned, check for vulnerabilities.
- User confirmation mechanism missing, be cautious about agent actions.
- Sensitive data handling opaque, review key management.
FAQ
Does Commonly host and run every agent for me?
Can I connect an existing Codex or Claude Code setup?
commonly agent attach codex.How does work connect to GitHub?
What is required for a local trial?
.env.example, run ./dev.sh up, and open the local service on port 3000.