ClawTeam for OpenClaw
Coordinate CLI coding agents as a self-organizing swarm with isolated workspaces, shared tasks, and direct messaging.
The evidence clearly describes the local JSON state directory, worktrees, process backends, messaging transports, and optional ZeroMQ, and recommends OpenClaw allowlist mode instead of full access. Test fixtures also redirect HOME and application data into temporary directories. Deductions apply because the framework can autonomously spawn agents, modify repositories, propagate OPENAI_API_KEY into containers, and enable --yolo or dangerous permission-bypass flags without demonstrated secret redaction, privilege minimization, comprehensive effect confirmation, or a retention policy. Cleanup, checkpoints, worktrees, and spawn auto-rollback are described, but the latter is mostly asserted. The README attributes the HKUDS/ClawTeam upstream and the MIT file preserves HKUDS copyright, while responsibility and identity for the current fork remain unclear.
The README, pyproject, CI configuration, and adapter tests coherently support Python 3.10–3.12, several CLI adaptation paths, and a cross-platform design. Installation checks and troubleshooting guidance are useful. Deductions reflect the absence of execution evidence, lack of Windows CI, and reliance on potentially unavailable external agents, tmux, the OpenClaw gateway, and an upstream Hermes fix. The README's 0.3.0, pyproject's 0.3.0+openclaw2, and website package's 0.0.0 also create minor version inconsistency. Failure handling is evidenced mainly by documentation and health-check claims rather than supplied implementation.
Developer audiences, agent-driven and manual workflows, software engineering, research, and investment-analysis scenarios are covered thoroughly. Linux, macOS, Windows, WSL, tmux, and subprocess accommodations are concrete, justifying strong audience and environment scores. Deductions apply because claims such as support for any CLI agent are broad, Cursor is explicitly experimental, and Hermes depends on an upstream version-specific correction. Natural-language triggers and Hermes routing rules are described, but the actual skill files are absent, so collision handling, false-trigger prevention, and complete parameter constraints cannot be verified.
The README has strong organization across installation, architecture, commands, platform differences, examples, troubleshooting, and integrations. Multilingual entry points, practical examples, local-install warnings, and a complete MIT license are notable strengths. Deductions apply because limitations are dispersed rather than maintained as a comprehensive list; spawn uses --team while launch uses --team-name, and Hermes adds positional-command conventions. Only a v0.3.0 feature summary is shown, with no systematic changelog or upgrade policy and inconsistent version strings. An issue tracker is identified, but the unknown fork publisher, upstream copyright, and pyproject author metadata do not clearly assign present maintenance responsibility.
Boards, inboxes, dependency tracking, isolated worktrees, templates, a Web UI, and claimed JSON output for all commands could produce directly usable coordination artifacts and offer meaningful value over manual orchestration. Deductions apply because major effectiveness claims—including the unique cost dashboard, production hardening, and experimental improvement figures—are not substantially supported by the supplied static files. The default file transport and installation footprint are relatively modest, but multi-agent operation can multiply model, GPU, process, and supervision costs, and the material gives no quantified resource limits or break-even guidance for ordinary tasks.
Several claims trace to pyproject metadata, CI, adapter tests, and the isolation fixture, including Python requirements, dependency ranges, command transformation, and temporary state placement. README statements about licensing and entry points receive partial corroboration from metadata. Deductions apply because many advanced features appear only as README bullets without corresponding implementation or tests in the supplied evidence. External experiment results, upstream synchronization, production-hardening claims, and competitive superlatives cannot be cross-checked here, and the documentation does not consistently distinguish tested facts, intended behavior, external case studies, and marketing inference.
- The OpenClaw setup allowlists clawteam for every agent. Scope that permission and review generated commands before enabling --yolo or permission-bypass modes.
- The container launch path can propagate OPENAI_API_KEY. Confirm that secrets cannot enter logs, prompts, shared inboxes, worktrees, or persistent JSON state.
- Team runs create processes, Git worktrees, and local state and may merge or clean branches; back up important repositories and verify confirmation and recovery behavior first.
- Windows, Hermes, ZeroMQ, cost dashboards, circuit breakers, and automatic rollback are not fully covered by the supplied CI or implementation evidence.
- Do not treat README performance figures, upstream-sync claims, or competitive statements as independently verified results.
What does this agent do, and when should you use it?
ClawTeam-OpenClaw is a fork of HKUDS/ClawTeam that makes OpenClaw the default worker while also supporting Claude Code, Codex, Hermes Agent, nanobot, and other CLI programs. Its `clawteam` CLI creates teams, spawns workers, records dependency-aware tasks, and coordinates agents through point-to-point inboxes and broadcasts. Each worker can receive its own Git worktree, identity, branch, and backend session, while team state is stored as JSON under `~/.clawteam/` without a required database or coordination server. Linux and macOS use a tmux-first workflow, while Windows 10/11 automatically falls back to the subprocess backend; terminal, tmux, and Web UI monitoring modes are available. It is aimed at teams that want existing coding agents to divide and merge complex work autonomously while retaining local isolation and operational visibility.
A leader creates a team with clawteam team spawn-team or instantiates predefined roles and tasks from a TOML template with clawteam launch. The clawteam spawn command then starts OpenClaw, Claude Code, Codex, Hermes, nanobot, or a subprocess command and provisions a worker identity, backend session, Git worktree, branch, and injected coordination prompt. Agents claim and update work through clawteam task create/update/list/wait; --blocked-by records dependencies and automatically unblocks downstream tasks after completion. They exchange findings with clawteam inbox send/broadcast/receive/peek over the default file transport or optional ZeroMQ P2P transport. The leader can checkpoint, merge, and remove worktrees with workspace commands, inspect the team through board show/live/attach/serve, and review per-agent, model, and task token costs with board cost. Team membership, tasks, inboxes, and workspace metadata live under ~/.clawteam/ as JSON protected by atomic writes and cross-platform file locking.
- An OpenClaw developer building a full-stack application can have a leader split architecture, backend, frontend, and testing work among isolated workers.
- A team using Claude Code or Codex can coordinate parallel code changes through shared task dependencies and inboxes without placing every worker in the same working directory.
- An ML researcher with multiple GPUs can assign different hyperparameter or architecture directions to separate research agents and circulate the best configurations.
- An investment research group can launch the
hedge-fundTOML template to create analysts, a risk manager, and a portfolio manager in a seven-agent workflow. - A Windows 10/11 user can run native multi-agent jobs with the subprocess backend and monitor them through the Web UI instead of tmux panes.
- A team mixing models or CLI agents can use per-role models, model tiers, and the documented seven-level resolution chain to balance capability and cost.
What are this agent's strengths and limitations?
- It coordinates multiple CLI agent products directly: OpenClaw is the default, while Claude Code, Codex, nanobot, and Hermes are documented as fully supported.
- Each worker can operate in a separate Git worktree and
clawteam/{team}/{agent}branch, with explicit checkpoint, merge, and cleanup commands for parallel development. - Dependency-aware tasks, automatic unblocking, inboxes, broadcasts, and monitoring boards are built in, so adopters do not need to write a separate orchestration program.
- The default architecture uses filesystem-backed JSON rather than a database or message queue, with optional ZeroMQ P2P for other deployment needs.
- Production-oriented controls include a live cost dashboard, retry with backoff, a circuit breaker, idempotency keys, runtime injection, and per-agent model selection.
- Installation requires cloning the repository and using an editable local install; the upstream PyPI package defaults to Claude and lacks these OpenClaw adaptations, while the similarly named npm package is unrelated.
- The complete tiled workflow depends on tmux. Native Windows cannot use
board attachand must use subprocess plusboard serve, or move the workflow into WSL. - OpenClaw adopters must install a skill and configure execution approvals, or spawned agents may stop at interactive permission prompts.
- Hermes session hygiene depends on an upstream fix for
--source tool; Hermes 0.8.0 and earlier ignore the flag, and some template workers may finish without sending results to the inbox. - Cursor support remains experimental, while full Windows support, A2A Gateway integration, a template marketplace, deep memory integration, authentication, and audit logs remain roadmap items.
How do you install or deploy this agent?
Prerequisites are Python 3.10+, Git, and at least one supported CLI coding agent. The full visual workflow on Linux or macOS also requires tmux. Install from the repository rather than running pip install clawteam, and do not install the unrelated npm package:
git clone https://github.com/win4r/ClawTeam-OpenClaw.git
cd ClawTeam-OpenClaw
pip install -e .For optional ZeroMQ P2P transport:
python -m pip install -e ".[p2p]"Verify the installation:
clawteam --version
clawteam config healthOpenClaw users must also install the supplied skill:
mkdir -p ~/.openclaw/workspace/skills/clawteam
cp skills/openclaw/SKILL.md ~/.openclaw/workspace/skills/clawteam/SKILL.mdSet the default security mode in exec-approvals.json to allowlist, then authorize the executable:
openclaw approvals allowlist add --agent "*" "$(which clawteam)"The repository also provides bash scripts/install-openclaw.sh for Linux, macOS, and WSL. In native Windows PowerShell, run py -3 -m pip install -e . from the repository and confirm that clawteam config get default_backend returns subprocess.
How do you use this agent?
For agent-driven operation, install ClawTeam and prompt a supported agent with: Build a web app. Use clawteam to split the work across multiple agents.
A minimal manual workflow is:
clawteam team spawn-team my-team -d "Build the auth module" -n leader
clawteam spawn --team my-team --agent-name alice --task "Implement OAuth2 flow"
clawteam spawn codex --team my-team --agent-name bob --task "Write unit tests for auth"
clawteam board serve --port 8080On Linux, macOS, or WSL, clawteam board attach my-team opens the tiled tmux view. Launch a built-in template with:
clawteam launch hedge-fund --team-name fund1 --goal "Analyze AAPL, MSFT, NVDA for Q2 2026"For Hermes templates, add --command hermes --force. For a manually spawned Hermes worker, supply hermes as the trailing positional argument.
How does this agent compare with similar options?
Compared with upstream HKUDS/ClawTeam, this fork makes OpenClaw the default and adds per-agent session isolation, execution-approval configuration, and hardened spawn backends; installing the upstream PyPI release instead defaults to Claude and omits these adaptations. Compared with OpenClaw alone, it adds autonomous task assignment, Git-worktree isolation, dependency unblocking, direct inbox communication, and kanban-style monitoring. The project also positions itself as a lightweight orchestration layer operated by agents through a CLI, using the filesystem and tmux or subprocess rather than requiring users to write framework-specific orchestration code or deploy databases and message queues.
FAQ
Does it require a database or central server?
~/.clawteam/ and uses file-based transport. A server is started only when you choose the Web UI with clawteam board serve; ZeroMQ P2P is optional.Is OpenClaw mandatory?
How does it prevent workers from overwriting one another's code?
clawteam/{team}/{agent} branches. The leader then manages their output with workspace checkpoint, merge, and cleanup commands.Can it run natively on Windows?
board attach still requires tmux, native Windows users should use board serve; WSL is the documented route to the full tmux workflow.What does it cost to operate?
clawteam board cost reports token and cost data by agent, model, and task.