ClawTeam-OpenClaw: A Swarm Coordinator That Treats CLI Agents as the Users

The Problem: CLI Agents Cannot Hand Work to Each Other

A single CLI coding agent holds one conversation and one working directory. When a task is large enough to split, the human is the one who opens a second terminal, copies context across, and merges the results by hand. ClawTeam-OpenClaw exists to move that coordination into the agents themselves. The README states the premise directly: current AI agents work in isolation, and the project lets them self-organize into teams that split work, communicate, and converge without human micromanagement. The intended user is not a platform engineer writing orchestration code. It is the agent, prompted with something like "Build a web app. Use clawteam to split the work across multiple agents." The human sets the goal and watches. That inversion matters for evaluation: the API surface is a CLI that agents call, not a Python SDK you import.

How Coordination Actually Works: Worktrees, Sessions, and a Task Board

The mechanism is deliberately unglamorous. When a leader runs clawteam spawn, the target worker receives three things according to the README: its own git worktree, a spawn backend session, and an identity. The worktree is a real branch, which is how the project claims isolation without containers. The backend session is where the agent process actually lives, either a tmux pane or a plain subprocess. Communication is also file-based rather than message-broker based. Workers run commands such as clawteam task list my-team --owner me and clawteam inbox send my-team leader "Auth done. All tests passing." Those commands are described as auto-injected into the worker prompt, which is the part that makes agent-driven coordination possible at all: the spawned agent does not need to be told the protocol, it arrives with it. Monitoring is a separate surface, clawteam board serve --port 8080 for a Web UI, or clawteam board attach my-team for a tiled tmux view. The transport badge lists File and ZeroMQ P2P, so there is a peer-to-peer option beyond the filesystem path, though the README's examples stay on the file side.

Getting It Running: Prerequisites, Install, and the Commands That Matter

The hard floor is Python 3.10 or newer plus at least one CLI coding agent. The README's check block is python --version, tmux -V on Linux, macOS, or WSL, and openclaw --version (or claude --version / codex --version). Installation of the agent itself is pip install openclaw across Windows, macOS, and Ubuntu. tmux is required for the full visual workflow on Linux and macOS, and is optional on Windows because the project defaults to the subprocess backend there. Creating a team is one command: clawteam team spawn-team my-team -d "Build the auth module" -n leader. Spawning workers follows the same shape, with clawteam spawn --team my-team --agent-name alice --task "Implement OAuth2 flow". Agent selection is positional, so clawteam spawn claude --team ... or clawteam spawn codex --team ... switches the backing agent, and clawteam spawn subprocess cursor --team ... covers the experimental Cursor path. Note that the README's Windows verification snippet is truncated mid-command at cla, so the exact backend-check invocation is not confirmable from the supplied material.

Windows Support Is Real but Partial, and board attach Is the Casualty

The platform section is unusually candid, which is worth crediting. Windows 10 and 11 fall back automatically to the subprocess backend, task locking and process liveness checks route through a shared compatibility layer, and unsupported Unix-only behavior is meant to degrade safely. The stated consequence is that board attach still requires tmux, so on Windows the README points you at clawteam board serve for live monitoring instead. If you want the original tmux workflow on Windows, the documented answer is to run ClawTeam inside WSL. That is a genuine limitation rather than a footnote: the tiled multi-pane view is the feature most associated with watching a swarm, and on native Windows it is unavailable. The fallback path also changes the process model, since subprocess sessions are not tmux panes, and the README does not describe how liveness checks differ between the two.

Where It Fits Badly: API-Only Agents and Container-Shaped Deployments

ClawTeam-OpenClaw assumes your agents are installed binaries on the same machine, reachable through a shell. If your agents are API calls behind a service, or if your execution environment has no persistent filesystem shared between workers, the core mechanism does not apply. The git worktree requirement is the sharper constraint. Spawning a worker creates a real branch in a repository, so the target directory must be a git repository and worktree operations must succeed there. A project that is not under version control, or one with a worktree-hostile layout, will not spawn cleanly. The comparison table in the README positions git worktrees against containers and virtual environments as the isolation strategy. That is a real trade-off, not a free win: worktrees isolate file state on a branch, but they do not isolate processes, dependencies, or system libraries the way a container does. Two workers on the same host share an interpreter and a package set.

The Real Alternative: Writing Your Own Orchestration Loop

The honest alternative is not another multi-agent framework. It is a script you write yourself: a loop that creates branches, launches agent processes, and collects their output. The README's own table frames the difference as who uses the tool, with ClawTeam aimed at the AI agents themselves and other frameworks aimed at humans writing orchestration code. If your workflow is stable and narrow, for example always spawning exactly three workers on fixed tasks, a hand-written loop is fewer moving parts and no new CLI to learn. ClawTeam-OpenClaw earns its place when the coordination is dynamic: the leader decides how many workers to spawn and what to assign them, and the injected task and inbox commands give those workers a shared protocol without you defining one. That is the specific thing a custom loop does not give you for free.

Maintenance, Upstream Sync, and What the MIT Licence Leaves You

This is a fork, and the release history shows the maintenance model clearly. v0.3.0+openclaw1 is titled Research-Backed Multi-Agent Intelligence, v0.2.0+openclaw.1 is an Upstream Security and Stability Sync, and v0.3.0+openclaw2 is Upstream Sync plus Auto-Respawn Hardening plus OpenClaw 2026.6 compatibility. The version suffix encodes both the upstream base and the fork's own revision, which tells you the project tracks HKUDS/ClawTeam rather than diverging permanently. The practical cost is that you inherit upstream churn: a security or stability sync upstream can land in your dependency without a fork-specific decision. The licence is MIT, which permits commercial and closed-source use, modification, and redistribution provided the copyright notice and permission notice are preserved. That is a statement about the licence text, not legal advice; if you ship this inside a product, have counsel confirm the notice obligations and check whether any bundled dependency carries different terms. The README does not enumerate dependencies or their licences.

Who Should Adopt It, and What to Confirm Before You Do

The fit is narrow and identifiable. You run OpenClaw, Claude Code, Codex, Hermes, nanobot, or a custom script as a CLI agent on Linux or macOS, tmux is installed, and you want agents to spawn and coordinate their own workers. In that setting the install is pip plus a prompt, and the transport is a filesystem you already have. You should not adopt it if your agents are remote API endpoints, if you need native Windows with the tiled board view, or if you want a managed service with a hosted dashboard. Before committing, verify three things in your own environment: that the chosen agent binary answers its version flag, that git worktree functions in the repository you intend to swarm, and that the Windows subprocess fallback behaves as documented if Windows is in scope. The README's Windows check command is truncated in the supplied material, so confirm the correct invocation from the repository itself rather than from the install section.

Editorial conclusion

Adopt ClawTeam-OpenClaw if you already run OpenClaw, Claude Code, Codex, or another CLI agent on Linux or macOS with tmux installed, and you want agents themselves to spawn and coordinate workers rather than writing your own orchestration. Skip it if your agents are API-only, if you need a Windows-first workflow with live board attach, or if you expect a hosted control plane. Before committing, verify that your agent binary responds to its version flag, that git worktree works in your target repository, and that the subprocess backend on Windows behaves as the README describes.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. win4r/ClawTeam-OpenClaw on GitHub