Muster runs your API, frontend, and workers as one named group — and keeps hold of them. Start it from the terminal, the editor, or an AI agent; the logs survive the crash, the restart, and the closed window.
The problem
Shells, task runners, and AI agents are all built around commands that start, do a thing, and finish. A dev server does none of that — it runs for hours, prints continuously, and only stops when something kills it. That single mismatch is where the whole day goes.
Ask an agent to start the dev server and it waits for a command that will never return. Every major agent has hit this — and had to build a workaround for it.
“Fixedclaude -p hanging forever after its final result when a backgrounded command never exits.”
Claude Code changelog · same pattern in Codex, Cursor, Copilot
Close the terminal and the output goes with it. So the one question you actually want answered afterwards — why did it crash? — has nothing left to read.
“Background tasks are automatically cleaned up when Claude Code exits.” Claude Code documentationWith no durable record of what it started, an agent starts it again — and collides with the port it bound itself a minute earlier.
“Claude keeps forgetting that it already started the dev server… started a second one even after it identified that the port… was already in use.” claude-code#9780Dev servers are noisy by design. Every line an agent reads is budget it isn't spending on your code — and one stuck process can dominate an entire session.
Measured on one bug: ~50K tokens per 10 exchanges became 581K — 11.6× waste. claude-code#11716None of this is any one tool's fault — it's what happens when a process that never ends meets tooling that expects one that does. Muster is the piece that holds the process. It starts your stack and returns immediately, keeps the logs on disk after everything exits, and hands both humans and agents the same typed handle on what's actually running.
How it works
Define once, commit it to the repo, and everyone on the team gets the same one-click stack.
Use the visual wizard — folder pickers, command suggestions, runtime detection — or write .vscode/muster.json by hand. Group your API, frontend, and workers with dependencies and delays.
One click in the sidebar — or muster run full-stack from any terminal. Muster opens terminals in your chosen layout — dedicated, aggregated, or split — and starts everything in order.
Live status per service in the tree. Errors and warnings from every terminal collected into one Events panel — filter by severity, group, or date, and click to jump to the source.
Features
One terminal per service, everything multiplexed into a single pane, or split panes across the editor — per group, your call.
Parallel or sequenced starts with dependsOn graphs and per-service delays. Your worker never boots before the broker again.
Gate dependents on a readyPattern regex in terminal output or an HTTP healthUrl check — not on hope.
A commands list per service, chained with && — install, migrate, then serve, without cramming one string.
Declare port once: it becomes the PORT env var, substitutes ${port} anywhere, and Muster warns before launch if something's already listening.
preRun/postStop commands per group — connect the VPN, docker compose up, run migrations — narrated, with failures aborting the run.
Explicit venv and nvm activation per service, with project auto-detection available as an opt-in setting — never forced on you.
Configurable regex patterns scan every service's output plus VS Code diagnostics. One timeline, filterable, click-to-navigate.
Blocked in untrusted workspaces. Only commands defined in config can run — no arbitrary shell. Your other terminals are never touched.
Every line is kept on disk as timestamped, greppable text. Stop the group, restart it, close the terminal — the crash you were reading is still there. Retention is per group: 7d, 48h, or none to keep it until you clear it.
Stopping interrupts the process and leaves the terminal, so a crash loop stays on screen to read. Restart reuses it and carries the history across a — restarted — divider instead of a blank screen.
muster daemon start hands your stack to a process that outlives the terminal that launched it — and the editor. Close everything; muster logs and every MCP tool still work.
Terminal native
Run your stack with muster up — no VS Code required: it reads your config, supervises the processes itself, and opens this exact dashboard — status dots, per-service logs, hotkeys, mouse, command palette. Quit and the whole tree stops with it. When VS Code is open, the same CLI becomes a remote control for the extension; when piped or in CI it degrades to clean prefixed logs.
:The command palette fuzzy-matches every live action — stop web finds stop full-stack/web. No keybindings to memorize.
Click rows to select, click a service again for its logs, click the footer buttons to act, scroll to move. A TUI that behaves like a UI.
Scaffold config, create and delete groups (muster create), stop or restart a single service without touching its siblings, follow and filter logs — from the terminal or the sidebar tree.
muster up needs no editor at all — the supervisor runs in your terminal with this same UI, an activity feed on the group row, and a quit that tears down every process. No orphans, ever.
MCP built in
Muster ships a native Model Context Protocol server. Agents in Claude Code, Cursor, Codex, and any MCP client can define, start, and read your groups through typed tools — no editor open, no arbitrary shell access, no watching a dev server swallow the conversation.
It never blocks. Starting a group hands it to Muster and returns immediately — the agent gets a status back instead of hanging on a process that never exits. Ask for logs when you actually need them.
Filtered, not firehosed. get_service_logs takes a severity and a substring, so an agent pulls the errors from api — a handful of lines — rather than pasting a megabyte of dev-server output into its context.
Scoped by design. Agents act only on IDs defined in your config; unknown ones are rejected. Defining a group only writes config. Anything that actually starts or stops a process waits for your OK — a prompt in the editor, or an explicit --allow-agent-actions when you run the daemon headless.
Works with no editor. The tools reach a running muster daemon or the VS Code extension, whichever is up:
Configuration
A single muster.json in your repo defines the stack for everyone. Schema-validated, wizard-editable, diff-friendly.
{ "groups": [{ "id": "full-stack", "label": "Full Stack Dev", "layout": "dedicated", "hooks": { "preRun": ["docker compose up -d db"] }, "services": [ { "id": "api", "command": "uvicorn main:app --port ${port}", "port": 8000, "cwd": "${workspaceFolder}/backend", "readyPattern": "startup complete" }, { "id": "worker", "command": "celery -A app worker", "dependsOn": ["api"] }, { "id": "frontend", "commands": ["pnpm install", "pnpm dev"], "port": 3000, "cwd": "${workspaceFolder}/frontend" } ] }] }
Install
On the Marketplace and on npm today — pick whichever fits how you work.
One-click install from the Extensions view — search for Muster, or:
View the listing ↗ · An Open VSX listing (Cursor, VSCodium) follows right after.
Clone, package, install — no build system beyond npm.
npm install -g puts muster and muster-mcp on your PATH in one command — no VS Code required. muster up runs your groups right in the terminal, dashboard and all.
Already have the extension installed instead? It offers to install the CLI itself the first time it sees a config — one click, no npm required.
The extension carries the CLI inside its own extension folder, and the editor puts that folder in a different place depending on where your code lives. That's invisible on macOS and Windows, and the whole story on WSL — so it's worth thirty seconds.
Install the extension, and the first time it sees a config it offers to put muster on your PATH — one click. It lands in /usr/local/bin, or ~/.local/bin when that needs sudo.
Same one-click offer, into %USERPROFILE%\.muster\bin. If a new terminal can't find muster, that directory isn't on your PATH yet:
These keep two separate sets of extensions — one for the editor's window, one for the machine your code is on. An extension installed on the Windows side is on a different filesystem from the shell you run muster in, so the install succeeds and the terminal sees nothing change.
Install it where the code is: open the folder in WSL first, then in the Extensions view use Install in WSL (or Install in Dev Container / Install in SSH). Then check which copy you actually got:
It prints the version and the file it resolved. On WSL that path must start with /home/ — if it starts with /mnt/c/, or the command isn't found at all, you installed on the Windows side.
npm link puts muster on your PATH pointing at your checkout — but a checkout with nothing built has no CLI to run, so it falls back to the installed extension's copy. You'd be editing one tree and running another. Build first:
The last line should print a path inside your checkout. If it doesn't, muster says so on stderr rather than letting you debug a fix you already made.
The extension carries the CLI inside its own extension folder, and the editor puts that folder in a different place depending on where your code lives. That's invisible on macOS and Windows, and the whole story on WSL — so it's worth thirty seconds.
Install the extension, and the first time it sees a config it offers to put muster on your PATH — one click. It lands in /usr/local/bin, or ~/.local/bin when that needs sudo.
Same one-click offer, into %USERPROFILE%\.muster\bin. If a new terminal can't find muster, that directory isn't on your PATH yet:
These keep two separate sets of extensions — one for the editor's window, one for the machine your code is on. An extension installed on the Windows side is on a different filesystem from the shell you run muster in, so the install succeeds and the terminal sees nothing change.
Install it where the code is: open the folder in WSL first, then in the Extensions view use Install in WSL (or Install in Dev Container / Install in SSH). Then check which copy you actually got:
It prints the version and the file it resolved. On WSL that path must start with /home/ — if it starts with /mnt/c/, or the command isn't found at all, you installed on the Windows side.
npm link puts muster on your PATH pointing at your checkout — but a checkout with nothing built has no CLI to run, so it falls back to the installed extension's copy. You'd be editing one tree and running another. Build first:
The last line should print a path inside your checkout. If it doesn't, muster says so on stderr rather than letting you debug a fix you already made.
Inside VS Code or Cursor with the extension installed, this is already wired up — see Agents above. From a terminal, or with no editor open at all, register muster-mcp with your client directly:
Install the repo as a plugin — registers the MCP server and the agent skill (the read → run → poll → stop workflow) in one step:
Or register the server directly
Verify with /mcp in a session — nine muster tools should list.
One command registers it:
Or add to ~/.codex/config.toml
Cursor doesn't read VS Code's MCP provider, so add it to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):
Then enable it under Settings → MCP.
Point it at the launcher — it finds the compiled server on its own, whether from an npm install -g or a checkout:
From a repo checkout
muster daemon or a running VS Code/Cursor extension, whichever answers. Headless, start the daemon with muster daemon start --allow-agent-actions first so run/stop/restart don't wait on a confirmation prompt nobody's there to click.