A control plane for resumable coding-agent workflows.
Define workflows in Markdown, run each stage through Claude Code, Codex, Gemini, Copilot, or any CLI, and keep the run record on disk.
Teams have spent the last year standardizing how coding agents behave: repo instructions, skills, MCP servers, provider settings, and internal conventions. What is still missing is the outer execution layer: how agent work is sequenced, resumed, reviewed, and inspected after the terminal session ends.
Crewplane turns coding-agent CLI calls into explicit, resumable workflows with local run records on disk. Write the workflow in Markdown, assign each stage to Claude Code, Codex, Gemini, Copilot, or any CLI, and Crewplane coordinates the run without replacing your agents.
| When agent work becomes... | Crewplane gives you... |
|---|---|
| A chain of shell scripts, prompts, and temp files | An explicit Markdown workflow with DAG execution |
| A long terminal session that fails halfway through | Resumable stage boundaries backed by preserved artifacts |
| Multiple agents reviewing, implementing, or synthesizing work | Clear dependencies, parallelism, handoffs, and review loops |
| Debugging by reading terminal scrollback | Rendered inputs, provider logs, intermediate outputs, manifests, and final results on disk |
| Trusting the run only while it happens | A local run record you can inspect later, keep when useful, or delete/archive when not |
No SDK rewrite. No provider lock-in. If your agent can run from the CLI, Crewplane can coordinate it.
Teams already define how agents behave with repo instructions, skills, MCP servers, provider settings, and internal conventions. Crewplane does not replace those pieces. It coordinates the work around them.
| Layer | What it controls |
|---|---|
| Repo instructions / skills | What agents should know and how they should behave |
| MCP / tools | What systems and context agents can access |
| Provider CLIs | The coding agents that do the work |
| Crewplane | How stages are sequenced, parallelized, retried, reviewed, resumed, and inspected |
Why not just use one agent CLI? For one-off tasks, you probably should. Crewplane is for agent work that becomes a workflow.
| Current pattern | Crewplane gives you |
|---|---|
| One long terminal session | Explicit DAG control with sequential and parallel stages |
| Copy-pasted prompts and temp files | Rendered inputs and outputs saved as run artifacts |
| Restarting from scratch after failure | Resumable execution from validated stage boundaries |
| Provider-specific glue | CLI-first orchestration across Claude Code, Codex, Gemini, Copilot, or any command |
| Black-box debugging | Logs, manifests, stage outputs, and final results you can inspect with normal tools |
Crewplane does not try to become your agent. It gives the agents you already use a shared execution plan, a workspace, and a run record.
Run the following on Mac or Linux to install Crewplane:
uv tool install crewplaneCrewplane can also be installed via the following package managers:
# pip
python -m pip install crewplane
# npm
npm install -g crewplaneWatch the installation flow if you want to see the command-line setup before running it locally:
installation.mp4
⚠️ Note: Crewplane does not install or manage provider CLIs or credentials. Install and authenticate Claude Code, Copilot CLI, etc. separately.
Other install methods (pipx, install script, local checkout) are documented in the installation guide.
From a project directory:
crewplane init
crewplane validate
crewplane run --no-livecrewplane init creates .crewplane/config.yml, a default workflow, and
additional example templates under .crewplane/workflows/example-templates/.
crewplane run --no-live then runs the workflow with a deterministic mock provider — no provider CLIs, API keys, or config edits required.
Inspect the artifacts:
- Stage run files:
.crewplane/execution-stages/ - Final results:
.crewplane/execution-results/
These files are the same shape you will see with real providers: each step has rendered inputs, outputs, logs, manifests, and final results you can inspect or diff with normal tools.
Treat run artifacts like build outputs: useful for debugging and review, but decide separately what, if anything, belongs in version control.
When you are ready to connect real tools, follow provider setup.
For interactive runs, drop --no-live to open Crewplane’s tmux dashboard:
Note: requires
tmux, install viabrew install tmuxon macOS orsudo apt install tmuxon Ubuntu/Debian.
crewplane runBecause the first run above already wrote a successful result, Crewplane will print
Identical context detected. That is the idempotency check.
To start a fresh interactive run, use:
crewplane run --forceNote:
--forceensures a fresh run, ignoring any cached successes.
The dashboard shows the workflow DAG, node status, selected provider output,
and live log tails while the same durable artifacts are written under
.crewplane/. See the
observability guide
for dashboard options and log inspection.
Workflows are Markdown+frontmatter; for example:
---
schema_version: "<current>"
name: "Quick Review"
nodes:
- id: review.project
mode: parallel
providers: ["mock"]
---
## review.project
Review the current repository and report the highest-risk issues.Full workflow authoring docs are in the workflow syntax reference.
After the mock path works, this walkthrough shows the shape of a first real provider run:
First real provider run
first_real_run.mp4
Safety boundary: Crewplane coordinates provider CLIs; it does not sandbox them, install them, or manage their credentials. Provider filesystem access, network access, approval mode, and authentication remain controlled by the provider tools you configure.
Use provider setup for the complete real-provider configuration path.
- 🔄 Explicit DAG Execution – Run independent stages in parallel and dependencies in sequence
- 🧭 Resumable Stage Boundaries – Reuse validated completed stages after duplicate, failed, or cancelled runs
- 📂 Inspectable Run Records – Rendered prompts, outputs, logs, manifests, and results written under
.crewplane/ - 🔌 CLI-First Providers – Coordinate Claude Code, Codex, Gemini, Copilot, Kilo, or generic commands
- 🖥️ Optional Live Dashboard – tmux view for DAG progress, node status, provider output, and log tails
- 🧪 Experimental Workspace Isolation – Git-backed worktrees and writable snapshots for isolating source-tree edits
For safety, security, and isolation details, see Security and trust.
Interested in contributing? Start with Contributing and local development.