Loom CLI
A CLI that runs parallel Claude Code sessions from your plan, each in its own git worktree, with stage checks and a knowledge base
- 66 ★ on the repository
- Last commit
- MIT
Broad access
Why this level
- Sessions run commands and edit code in worktrees without constant confirmation, though inside a sandbox
- Tokens are spent on several sessions in parallel and cost depends on plan size
- The web dashboard bound to another address exposes terminals over plain HTTP
Install
- Works in
Manual install
curl -fsSL https://raw.githubusercontent.com/cosmix/loom/main/install.sh | bashNeeds `git`, `claude`, `jq`, `minisign`. Signed binaries for Linux x86_64 and Apple Silicon macOS.
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- Sessions run commands and edit code in worktrees without constant confirmation, though inside a sandbox
- Tokens are spent on several sessions in parallel and cost depends on plan size
- The web dashboard bound to another address exposes terminals over plain HTTP
This is third-party code. Review the repository files before installing.
What it does
Loom runs a development plan you have already discussed with an agent. The plan is written by the `/loom-plan-writer` skill into `doc/plans/PLAN-<name>.md` and split into stages with a dependency graph. Independent stages run at once, each in its own git worktree, and merge back as they finish. Loom decides what is done on its own: it runs each stage's acceptance criteria and inspects the tree for stubs and code nothing calls. After all stages merge, a separate `integration-verify` stage checks the result as one system. Session mistakes are recorded and, at the end of a plan, distilled into a knowledge base in your repository that the next plan starts from. Shell hooks enforce rules such as commit discipline, worktree boundaries and subagent limits. Sessions run in a filesystem and network sandbox. Progress shows in the terminal with `loom status --live` or in a browser with `loom status --web`, and any session can be taken over. Expensive models go only to the orchestrator, while implementation goes to the cheapest suitable subagent, Claude or Codex.
Who it is for. Experienced developers who design the system themselves and want to hand implementation to parallel Claude Code sessions under control.
Good fit when
- A large feature splits into independent parts that are sensible to build at once
- A plan needs review: `loom plan verify` and `loom pressure` find weak spots before tokens are spent
- A project knowledge base is wanted that grows between plans and reduces repeated mistakes
- The run happens on a remote machine over SSH or in WSL, where the tmux session backend fits
Not a fit when
- The task is one or two files: the overhead of a plan and stages does not pay off
- There is no ready plan and you want to give the agent a goal and wait for a result
- A platform other than Linux x86_64 or Apple Silicon macOS is needed: other systems build from Rust sources
Example request
/loom-plan-writer Split the API migration into stages with dependencies and acceptance criteria, then check the plan with `loom plan verify`Limitations
Running it needs `git`, the `claude` CLI, `jq` and `minisign` to verify the downloaded release. Signed binaries exist for Linux x86_64 and Apple Silicon macOS, and other platforms build with `cargo`. Codex mode needs the `codex` CLI and its plugin installed, otherwise tasks fall back to Sonnet and Haiku and a warning appears at startup. The project is under active development and command behavior changes. The web dashboard listens on `127.0.0.1` by default, and binding to another address serves data over plain HTTP. Token spend depends on plan size and the number of parallel sessions.
How to disable. Stop the daemon with `loom stop`, delete the `loom` binary (by default in `~/.local/bin`) and the project hooks that `loom init` installed.
FAQ
How do I install Loom for Claude Code?
Run the installer with `curl -fsSL https://raw.githubusercontent.com/cosmix/loom/main/install.sh | bash`. It needs `git`, `claude`, `jq` and `minisign`. For platforms without signed binaries, build from source with `cargo`.
How do I run a first plan?
Write the plan with `/loom-plan-writer`, check it with `loom plan verify`, then run `loom init <plan>`, `loom run` and `loom status --live`. `loom stop` ends the run.
How does Loom verify what sessions did?
It runs each stage's acceptance criteria itself and inspects the tree for stubs and unwired code, ignoring the agent's own claim of completion. After all stages merge, a separate stage checks the system as a whole.
Can I watch the sessions and step in?
Yes. The terminal dashboard `loom status --live` and the web dashboard `loom status --web` show stages and context use. Open a session with `loom attach` or the browser terminal and take over the keyboard.
Is Codex required?
No, Codex is optional. With it Loom hands part of implementation to Codex models and can run `loom pressure` with two model families. Without the `codex` CLI, use `/pressure` inside Claude Code.
Discussion
No questions or reviews yet.
Related
CLI toolsLACP runs Claude Code, Codex and Hermes through local policy gates, budgets and an evidence log, and rolls back failed changes
A planner for Claude Code, Codex and OpenCode: one goal becomes a task plan and independent tasks run in parallel
Skills for cross-provider work between Claude Code and Codex: one agent drafts the plan, the other reviews it, then a build and an independent code inspection f
A local web interface over Claude Code: drafts plans with feature recipes, runs them as an agent crew, checks them against git.
Claudette runs several Claude Code sessions in parallel, each in its own git worktree, from a window or the console
CLI for parallel agents: splits a task into sections, runs Codex, Claude Code or OpenCode together and merges into one branch
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Repository stars | Main difference |
|---|---|---|---|
| Loom (this card) | no | 66 | |
| Agent Swarm operator skill | no | 1,048 | an agent swarm with a shared queue, whereas Loom executes a pre-verified plan by stages with independent verification |
| metaswarm | no | 430 | a multi-agent framework with roles, whereas Loom builds a stage graph in worktrees and accumulates a project knowledge base |
README in short
The README describes an approach where the human thinks through the plan and Loom spends tokens on execution. It then covers quick start, the verification model, hooks, the sandbox, model allocation and the web dashboard.