dispatch
Sessions waiting on you:0finished:0· all quiet
Sign inGet early access

Docs

Planning

Install the MCP server, then let a lead session open the day's terminals itself — each in the right repo, each seeded with its own prompt.

The broadcast bar is one command → many terminals. This is the other half — many different jobs → many terminals.

Keep one Claude Code session as the lead: a tile you talk to rather than work in. Tell it what your morning looks like and it opens the terminals itself.

I’ve got BUG-114 in vantage, BUG-118 in Aura-Tycoon, and two chores in meme-factory. Set them up.

They come up armed: the command is typed into each shell and left sitting at the cursor, not run. You read down the row, see exactly what each one is about to do, and press Enter on the ones you agree with. Armed tiles glow amber like a completion ping, because they are also waiting on you.

Ask for mode: "fired" when you’d rather they just go.

Setting it up

Click Install MCP for Claude Code at the bottom of the sidebar. It writes a dispatch entry into your user config — the same one claude mcp add --scope user writes — pointing at the copy of the server inside the build you clicked it from, so a checkout and an installed copy each register themselves correctly with no path to type.

The button is the status too. Green once it’s registered; amber if the entry survives but points at a server somewhere else, which is what a moved or reinstalled Dispatch leaves behind — click it to repoint.

Claude Code reads the config at startup, so sessions already running won’t see the tools until they restart.

From the CLI

# running from a checkout
claude mcp add dispatch --scope user -- node H:\path\to\terminal-dispatch\mcp\dispatch-mcp.js

# or against an installed build, where it is unpacked beside the asar
claude mcp add dispatch --scope user -- node "$env:LOCALAPPDATA\Programs\Dispatch\resources\app.asar.unpacked\mcp\dispatch-mcp.js"

Either way Dispatch must be running — the tools talk to the live window over a local named pipe, since that window is the only thing that honestly knows what is open. When it isn’t running, every tool says so rather than guessing.

The tools

Tool What it does
dispatch_projects Every project it can open, with path, group, type and git branch. The lead calls this first to map tickets to repos.
dispatch_plan Opens a set of terminals in one go — the main one. A tile can carry a doc instead of a prompt, so a planned workspace comes up with its plan already open beside the work.
dispatch_doc Opens a markdown file as a tile. See Documents.
dispatch_list What’s open right now: project, title, still-armed, waiting-on-you, exited — plus each terminal’s status (needs-you / done / working / exited) and how long it’s been quiet.
dispatch_send Types into an open terminal; multi-line text is pasted as a block.
dispatch_read Reads a terminal’s text back out — the tail of what’s on screen and above it. How the lead finds out what a session answered.
dispatch_wait Blocks until a session rings, exits or goes quiet, then says which and why. How the lead supervises without polling.
dispatch_rojo The sync switch from a session — which is what makes “check before you edit” something an agent can do.
dispatch_workspace Switches to, renames, or closes a workspace.
dispatch_close Closes a tile and ends its shell.

A plan is all-or-nothing

Every project reference is resolved before anything is created, so a plan naming a repo that can’t be found opens no terminals rather than half of them.

A name matching more than one project is an error listing the candidates — never a guess, because a tile opened in the wrong repo is an agent working confidently on the wrong code.

Where the tiles land

By default they land in a new workspace, so a plan never disturbs what you’re already doing. Pass workspace: "current" to add them to the one on screen.

Supervising without polling

dispatch_wait is the piece that makes a lead session practical: it blocks until a session rings, exits or goes quiet, then reports which and why. Combined with dispatch_read, a lead can set up five jobs, wait for whichever finishes first, read what it said, and decide what to do next — without a loop that burns tokens asking “are you done yet”.

Removing it

Same menu. Nothing outside the dispatch entry is touched: the file is parsed, modified and written whole, a .dispatch-backup is kept beside it, and a config that doesn’t parse is refused rather than rewritten.