ClawTeam-OpenClaw: a multi-agent swarm CLI with OpenClaw as the default agent

The problem ClawTeam-OpenClaw targets: one agent, one context window

A single CLI coding agent works inside one context window and one working tree. ClawTeam-OpenClaw takes the position that coordination should be done by the agents themselves rather than by a human writing orchestration code. The README frames the comparison directly: in ClawTeam the users are "the AI agents themselves", while other multi-agent frameworks are for "humans writing orchestration code".

This fork exists because the upstream project HKUDS/ClawTeam was not built around OpenClaw. The fork note says it adds a default openclaw agent, per-agent session isolation, exec approval auto-config, and hardened spawn backends, and that all upstream fixes are synced. If you run OpenClaw and want a leader to hand out subtasks, that default matters: the plain spawn command produces an OpenClaw worker without you naming the agent type.

The intended audience is narrow. You need at least one CLI coding agent installed and a repository you are willing to have several agents write into at once. It is a developer tool for people comfortable reading CLI output and git history, not a hosted service.

How the swarm actually works: worktrees, a spawn backend and a CLI-injected protocol

The mechanism is deliberately unglamorous. When the leader calls spawn, each worker gets three things: its own git worktree, its own spawn backend session, and an identity. The worktree is a real branch, so two workers editing the same file do not collide in the filesystem. That is the isolation story, and the README contrasts it with containers or virtual environments used by other frameworks.

Transport is either the filesystem or ZeroMQ peer-to-peer; the p2p extra pulls in pyzmq and the redis extra pulls in the redis client, both optional in pyproject.toml. The default path needs no broker, which is why the setup table claims filesystem plus tmux rather than Redis or a message queue.

Communication is not a library the agent imports. The CLI commands are auto-injected into the worker's prompt, so a worker checks its inbox, lists its tasks and reports results by running clawteam subcommands. The README shows a worker sending a message with `clawteam inbox send my-team leader "Auth done. All tests passing."`. The leader is the coordinator; you are the observer, watching through a tiled tmux view or the web board on port 8080.

Installing ClawTeam-OpenClaw and spawning your first two workers

The prerequisites are Python 3.10 or newer and at least one CLI coding agent. On Linux and macOS the full visual workflow also needs tmux; on Windows tmux is optional because ClawTeam falls back to the subprocess backend. The README suggests checking what you already have before installing anything:

python --version    # Need 3.10+
tmux -V             # Linux/macOS/WSL only
openclaw --version  # Or: claude --version / codex --version

If OpenClaw is missing, the README's install table gives `pip install openclaw` for Windows, macOS and Ubuntu/Debian alike. With the prerequisites in place, create a team and spawn two workers. Each spawn call allocates a git worktree and a backend session, so run this from inside the repository you want the swarm to modify:

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 --team my-team --agent-name bob   --task "Write unit tests for auth"

To watch progress, serve the web board on port 8080, or attach the tmux view on Linux, macOS or WSL. The README notes that `board attach` still requires tmux, so on native Windows `board serve` is the live monitoring path:

clawteam board serve --port 8080
clawteam board attach my-team   # Linux/macOS/WSL with tmux

The faster route the README recommends is to let the agent drive: install ClawTeam, then prompt your agent with something like "Build a web app. Use clawteam to split the work across multiple agents." The agent creates the team, spawns workers and assigns tasks through the same CLI you would type by hand.

Windows, tmux and the parts that degrade instead of failing loudly

The platform section is the most honest part of the README, and it is where a Windows user should slow down. Task locking, process liveness checks and signal registration are routed through a shared compatibility layer so that Unix-only behaviour degrades safely rather than crashing. Degrading safely is not the same as behaving identically, and the README does not enumerate what is lost.

Two concrete constraints are stated. First, `board attach` requires tmux, so Windows users are pushed to `clawteam board serve`. Second, if you want the original tmux workflow on Windows, the README tells you to run ClawTeam inside WSL. That is a real fork in the road: a native Windows install gets the subprocess backend and the web board, while a WSL install gets the tmux-first workflow the project was originally designed around.

The agent support table marks Cursor as experimental and reached through `clawteam spawn subprocess cursor --team ...`, whereas OpenClaw, Claude Code, Codex, nanobot and Hermes Agent are listed as full support. Custom scripts go through the same subprocess path, for example `clawteam spawn subprocess python --team ...`.

Where ClawTeam-OpenClaw is the wrong tool

The package metadata classifies it as Development Status 3 - Alpha, and the version string of the latest release is v0.3.0+openclaw2, a local-version suffix that signals a fork tracking an upstream rather than a stable line. If your team needs a frozen API contract or a long support window, that is the wrong shape.

The second limitation is environmental. Multiple agents writing to one repository at once is the whole point, but the isolation unit is a git worktree, not a container. Nothing in the README suggests resource limits, network sandboxing or per-worker secrets. If your workers need to run untrusted code, or you need each one to see a different dependency set, worktrees do not provide that boundary and a container-based orchestrator is the better fit.

Third, the project assumes a terminal. The board is a tmux view or a web page; there is no hosted control plane. If you want a managed service with a dashboard, audit log and role-based access, this is not it. And if you only ever run one agent on one task, spawning a team adds a leader, a worktree per worker and a coordination protocol for no gain.

How it differs from writing your own orchestration layer

The obvious alternative is a framework where you write the graph: define nodes, edges and state, then run it. The difference is who holds the plan. In a code-defined framework, you decide up front how many workers exist, what each one receives and when the run ends. In ClawTeam-OpenClaw, the leader agent decides, calling spawn as it sees fit and messaging workers through the CLI that was injected into their prompts.

That shifts failure modes. A hand-written graph is reproducible and debuggable step by step; an agent-driven swarm adapts to what it finds but its coordination decisions are only as good as the leader model. The README's own comparison table puts setup at `pip install` plus one prompt against Docker, cloud APIs and YAML configs, and infrastructure at filesystem plus tmux against Redis, message queues and databases. Those are the trade-offs in plain terms: less to operate, less to pin down.

A narrower alternative is running several agent sessions by hand in separate terminal panes. You keep full control and pay for it in attention. ClawTeam-OpenClaw replaces that attention with a leader agent and a board, which is worth it only when the task genuinely splits into independent pieces.

Licence, fork maintenance and upgrade cost

The licence is MIT, declared both in the LICENSE file and in pyproject.toml as `license = {text = "MIT"}`. MIT is permissive, so redistributing a modified copy inside a commercial product is permitted provided the copyright notice and permission notice travel with it. That is the general shape of the licence, not legal advice for your situation.

The maintenance question is more interesting than the licence. This is a fork, and the fork note says all upstream fixes are synced, with the latest release titled "Upstream Sync + Auto-Respawn Hardening + OpenClaw 2026.6 Compat". The version scheme encodes the relationship: v0.3.0+openclaw2 is upstream 0.3.0 plus fork-local revisions. The last push to the repository was on 2026-07-03, so the code has not moved since then.

The upgrade cost follows from that scheme. You are tracking two moving targets at once: the upstream ClawTeam and the OpenClaw version the fork is adapted to. The 2026.6 compatibility note in the release title means an OpenClaw upgrade can require a matching ClawTeam-OpenClaw release. The dependency bounds in pyproject.toml are conventional caret-style ranges (typer, pydantic, rich, questionary, mcp), so a fresh install can resolve to newer minor versions than the fork was tested against. If you pin, pin the agent version alongside the package.

Editorial conclusion

Adopt it if you already drive OpenClaw, Claude Code or Codex from a terminal and want several instances on one goal without writing orchestration code. Skip it if you need a stable, versioned API surface: pyproject.toml still classifies the package as Development Status 3 - Alpha. Verify first that Python is 3.10 or newer, that the agent binary you intend to use answers --version, and on Windows that the fallback to the subprocess backend is what you want, since board attach still requires tmux there.

Frequently asked questions

Official sources

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