Claw-Empire: A Local-First Office Simulator for CLI and API Agents

The problem Claw-Empire addresses is provider sprawl, not agent capability

Running one coding agent is a terminal session. Running five is a bookkeeping problem. Claude Code, Codex CLI, Gemini CLI, OpenCode, Kimi Code, GitHub Copilot and Antigravity each carry their own authentication model (CLI session, OAuth, or a direct API key), their own invocation syntax, and their own notion of a working directory. Claw-Empire's pitch is that these become interchangeable employees inside one dashboard, with tasks, departments and deliverables tracked in a local SQLite database rather than scattered across shell history. The target user is a solo developer or small team already paying for more than one of these providers and looking for a way to assign work across them without writing bespoke glue. It is explicitly not a hosted service: the README describes it as local-first and private, with all data staying on the machine and no cloud dependency. That framing matters, because it means the orchestration layer is something you operate, not something you subscribe to.

Office packs define the org chart, and that is the real configuration surface

The most consequential design decision in Claw-Empire is that an agent's role is not configured directly. It is inherited from an office pack, and the pack determines the collaboration topology, a naming seed, and a workflow bias. Six packs are documented: development (DEV), report (RPT), web_research_report (WEB), novel (NOV), video_preprod (VID) and roleplay (RPG). Each one maps to a different representative structure. The development pack runs Planning, Development, Design, QA-QC, DevSecOps and Operations. The web research pack runs Research Strategy, Crawler Team and Fact Check. The video pre-production pack runs Pre-production, Scene Engine, Art and Camera, and Cut QA. This is a stronger abstraction than a flat list of agents, because the department names carry implied handoff semantics: a Fact Check desk exists to challenge a Crawler Team, and a Tone QA role exists to constrain a Narrative Engine. The trade-off is that if your workflow does not resemble any of the six packs, you are working against the grain of the model rather than with it. The release notes for 2.0.4 also state that API model assignment starts from the development pack and expands to office packs that have already been hydrated through initial setup, which suggests packs are not purely declarative: they have a setup step, and only hydrated packs appear as assignment targets.

Agents work in isolated git worktrees, which is the mechanism worth understanding

The README states that agents work in isolated git worktrees and produce deliverables. This is the part of the architecture that has the clearest engineering consequence. Parallel agents editing the same checkout would collide on the working tree, on index locks, and on any file both of them touch. Worktree isolation means each agent gets its own checkout rooted at the same repository, so their file writes do not stomp each other and the resulting branches can be reviewed or merged separately. The cost is disk and merge overhead: every worktree is a full checkout, and someone still has to reconcile the branches afterward. Claw-Empire does not appear to solve that reconciliation problem; it moves it. If you have ever spent an afternoon resolving overlapping diffs from two agents that both decided to refactor the same module, you will recognize this as a real improvement in failure mode rather than an elimination of it. The lifecycle behaviour described in the 2.0.4 notes is consistent with this model: startup and interval sweeps reset agents still marked working without a live in_progress task, which is what you would expect from a system where a crashed agent can leave a worktree in an ambiguous state.

Getting it running: two documented paths and a long provider checklist

The README's quick start is a pnpm workflow. The repository declares Node.js 22 or newer, and the release notes reference pnpm run test:e2e for the Playwright end-to-end suite, so pnpm is the package manager the project expects. Beyond that, the README documents a Docker deployment path as an officially supported route as of 2.0.4, with a production-oriented Dockerfile, a docker-compose.yml, a .dockerignore and container-aware runtime path handling. That matters for anyone who does not want a global Node install on the host. Provider setup is the long pole. Each of Claude Code, Codex CLI, Gemini CLI, OpenCode, Kimi Code, GitHub Copilot and Antigravity has to be reachable, and the 2.0.4 notes describe Settings > API presets for OpenCode Go and Bailian Coding Plan that lock the expected Base URL, seed fallback models immediately, and keep refresh and retry behaviour explicit. There is also an OpenClaw integration path and a Direct Messenger mode described as working without OpenClaw, plus a $ command whose logic the README links to. The honest summary is that the README gives you the shape of the setup, not a copy-pasteable sequence for every provider, and you should expect to consult the per-provider sections rather than a single script.

What the documentation does not settle

Several things a prospective operator would want to know are not resolvable from the supplied material. The README links docs/api.md and docs/openapi.json, which implies a documented HTTP surface, but the material here does not state whether that API is considered stable across minor versions, or whether it is intended for external consumers at all. The skills library is described as 600+ agent skills across categories, with a learn and unlearn flow and prompt-skill rendering mentioned in the 2.0.4 notes, but there is no description of where those skills come from, how they are versioned, or what happens when a skill's prompt drifts from the provider it targets. The scheduling semantics are similarly opaque: the release notes mention interval sweeps and lifecycle startup, which tells you a scheduler exists, but not how concurrency is bounded, how a task is retried after a provider error, or what happens when two agents are assigned the same deliverable. None of this is evidence of a defect. It is evidence that the README is written for someone who wants to try the simulator, not for someone who has to operate it under load. Treat the source and docs/api.md as the actual specification.

The wrong tool for multi-tenant or compliance-bound work

Claw-Empire is local-first by design, and that is a boundary, not a marketing line. If your requirement is that several people share one orchestration service, that audit logs be centrally retained, or that agent credentials never sit on an individual workstation, this project is pointed the other way. The SQLite database and the on-machine provider credentials are the architecture, and the README's security section is linked rather than summarized, so you should read SECURITY.md before assuming anything about credential handling. A second case where it is the wrong tool: if you need deterministic, reproducible agent runs for CI. The pixel-art office and the meeting metaphor imply a simulation loop with human-visible state, and a simulator is not a batch runner. A plain shell script that invokes one CLI agent with fixed arguments will be easier to reason about in a pipeline than an orchestrator whose scheduler semantics you have to reverse-engineer. Claw-Empire is for exploration and parallel work on a machine you control, not for regulated environments or unattended production pipelines.

How it compares with a general-purpose agent framework

The obvious alternative category is a general-purpose agent framework such as LangGraph or CrewAI, where you define agents, tools and graph edges in code and run them as a Python service. The difference in approach is stark. A framework gives you a programming model and leaves the user interface, the persistence layer and the provider abstraction to you. Claw-Empire gives you the interface and the persistence layer and leaves the programming model implicit in the office packs. If you want to express a custom control flow with conditional edges, retries and typed state, a framework is the better fit, because that is literally what it is for. If you want to see five CLI agents working in parallel on one repository and track their output in a board, Claw-Empire addresses that directly and a framework would require you to build the board first. The second alternative is doing nothing: running each CLI agent in its own terminal and keeping a text file of assignments. That has no dependency graph, no worktree isolation, and no dashboard, but it also has no scheduler to debug. The honest comparison is that Claw-Empire's value is proportional to how many providers you already juggle and how much you dislike tracking them by hand.

Maintenance cost and the Apache-2.0 licence

The release cadence visible here is fast. v2.0.2, v2.0.3 and v2.0.4 all landed within five days of each other in March 2026, and the last push to main is dated 2026-03-16. Three patch releases in a week is a signal about both activity and churn, and it means you should pin a version rather than track main if you intend to rely on it. The 2.0.4 notes also describe a behaviour change in the test harness: pnpm run test:e2e now resets the isolated runtime before and after Playwright runs, and existing servers on port 8810 are no longer reused unless you explicitly opt in. That kind of change is exactly the sort of thing that breaks a local setup built against the previous behaviour, so read the release notes before upgrading. The project is Apache-2.0, which permits commercial and private use and includes an explicit patent grant, but it also requires that you preserve copyright and licence notices and state significant changes if you redistribute. Apache-2.0 does not grant trademark rights, so the Claw-Empire name and logo are not yours to reuse in a fork. This is a description of the licence text, not legal advice; if you plan to redistribute a modified version, have someone qualified read the NOTICE requirements.

Editorial conclusion

Adopt Claw-Empire if you already run several CLI coding agents on one machine and want a single dashboard with task tracking, provider presets and git worktree isolation. Do not adopt it if you need a documented multi-tenant deployment, a stable public API contract, or an orchestrator whose scheduler semantics you can reason about without reading the source. Before installing, verify that Node.js 22 or newer is available, decide whether the Docker path or the pnpm path fits your environment, and read docs/api.md and docs/openapi.json to see how much of the runtime is actually specified.

Official sources

1. GreenSheep01201/claw-empire on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases