Repository navigation
v4.3.0 - Boards, account failover and the finished UI rebuild
One Dispatch used to mean one board. A second project shared the columns, the sessions folder and the repositories of the first, and you kept the two apart in your head. When a Claude account hit its usage limit, every session on it stopped. You switched the account by hand and restarted each session.
This release gives Dispatch more than one board. It moves live sessions to another Claude account at a safe point, and with automatic moves on, it fails over along a chain of accounts. It also finishes the shadcn rebuild of the app. The first start migrates board.db once and keeps a copy of the old file. Everything you have today lands on the default board, Local, with the same ids.
Boards
Open the boards page from the command palette with Manage boards or New board. A board has a key, a name, a sessions folder and at least one git repository. The key is 2 to 6 capital letters or digits and starts with a letter. LOCAL and GROUP are reserved, and you cannot change a key later.
With two or more boards, a switcher appears at the top of the sidebar. Click it, press B, or use Switch to board in the palette. Ten pages follow the selected board: Board, Inbox, Today, Tickets, Sessions, Workspace, Workspaces, Flow, Activity and Archive. The URL carries the board as ?board=ACME, so a link opens the same board. Settings, Vault, Accounts and Connections stay global. An open terminal stays live through a switch. A link to a card on another board switches to that board.
A card on a new board takes the board key as its id: ACME-1, ACME-2. Its session starts in the sessions folder of that board, and its tmux session is dsp-ACME-1. A new Linear issue goes to the board that lists its team in Linear team keys. Other Linear issues and other sources go to Local. Each row on the boards page shows running sessions, open groups and cards that need your input. Archive hides a board, and Restore shows it again. Dispatch refuses to archive a board while one of its sessions runs, and Local cannot be archived.
A new board starts with the session supervisor on. On such a board, Dispatch acts in your sessions without asking:
- It sends one continue prompt after an API error, or after a turn that ended when the Mac slept.
- It declines a dangerous delete prompt and a peer message prompt.
- It starts Claude again in a session that lost it, then sends a resume prompt.
- It answers the usage limit dialog.
- It keeps the Mac awake with
caffeinatewhile a supervised session runs.
Local keeps the supervisor off. The app has no control for it yet. To disable it for a board, send the full board policy with "supervisor": "off" to PUT /api/boards/<KEY>/policy.
Accounts that move with your sessions
Switch the active account on the Accounts page and choose which running sessions follow: none, the idle ones, or all. All is the default. An idle session moves at once. Dispatch exits Claude, starts it again on the new account and resumes the same conversation. A busy session moves when its current turn ends, because Dispatch never interrupts a turn. If the shell does not return within 15 seconds, the move stops and changes nothing. Each session row and the detail header now show the account of that session. A stale badge and Restart appear when the Default login changed under the session.
The Accounts page also holds a chain. Drag the accounts into order. Dispatch reads usage every 15 minutes. For the account in use, it reads every 2 minutes while one of its buckets is above 80 percent. The threshold is 100 percent by default, and you can set it from 50 to 100. Three signals mark the account in use as limited: usage at the threshold, the limit screen in a session, or a rate limit error. Dispatch then picks the first account in the chain that is not limited.
- With Automatic moves on, sessions move to that account at a safe point. Pinned sessions stay where they are.
- After a move, a usage reading starts no new move for 15 minutes. A limit screen or a rate limit error still does.
- At the reset time plus 2 minutes, Dispatch reads usage again. If the earlier account is free and ranks higher, sessions return to it.
- If every account is limited, nothing moves, and the page shows the earliest reset.
- Switch now moves every unpinned session at once.
Automatic moves are off by default. With them off, Dispatch sends a notification, and the page offers Switch now. The page states: "Anthropic's terms do not address automatic moves between your own accounts." Read that before you enable them. On a limit screen, Dispatch never picks a credit, extra usage or upgrade option. Sign-in through the app now waits 10 minutes instead of 3, because a slow sign-in to a second account timed out and lost the account.
The rebuild is finished
Versions 4.1 and 4.2 moved the app frame and eleven pages to shadcn. This release moves the rest: the board, Inbox, Today, Ask, Activity, Flow, the detail panel, Sessions, Workspace and every card dialog. The old component tree is deleted. The rule stayed the same: everything behaves as it did. At the cutover, the copy, network and action comparisons against the old tree were empty, and the terminal never remounted.
A few things are better. Focus returns to the control that opened a menu, a popover or the detail panel when it closes. Links to pull requests, previews and tickets open only http and https addresses. The Agent done column header no longer wraps or clips. A Playwright suite checks 28 screenshots of 7 screens at two widths in both themes, and loads 20 routes with no console error. It runs in CI on every pull request.
Underneath: groundwork for the orchestrator
The next release adds an orchestrator: a Claude session that runs the roadmap loops of a board for you. Its server parts are in this release. They have no screen yet.
- Loop progress:
POST /api/loops/reportputs roadmap loop progress and session meters on the card. - A session supervisor with 12 session states, and a policy for each board at
PUT /api/boards/<KEY>/policy. - An orchestrator control surface of 23 routes under
/api/orchestrator. Its tokens come fromPOST /api/boards/<KEY>/orchestrators/<id>/token, and Dispatch stores only their SHA-256 hashes. User routes refuse them. - Decision items, and a stacked branch ship flow that pushes or merges only when the
shipRightsof the board allows it. The default isnone. dispatch mcp, a stdio MCP server with 23 tools for the orchestrator session. Dispatch does not start it at boot.- The design records are in
docs/standards/orchestration-design.mdanddocs/standards/orchestration-ui-spec.md.
This adds one runtime dependency, @modelcontextprotocol/sdk 1.32.1.
Known limits
- Boards: you cannot drag a card between boards. The attention count is the Needs input column only. Ask answers from Local only. Inbox items show on every board. Archive hides a board but does not stop its work.
- While Linear is off, Dispatch cannot refuse a board key that a Linear team also uses. Then tmux names, branches and worktrees can clash with that team's cards. Pick a key no Linear team uses.
- With one board, the app sends one extra request at load,
GET /api/boards. Every other request is unchanged. - Accounts: push notifications for failover, return and an exhausted chain were not tested on a live push service. Work returns only on the reset timer, not when usage drops.
- In pane status mode, a session with no recorded conversation id starts a new conversation after a move instead of resuming. At 390 pixels, a narrow panel can hide the usage limit banner of a session.
- Calendar on macOS and the Slack connector from the accounts work are not in this release.
- The Start and Group start dialogs do not return focus to the control that opened them. A failed terminal start still has no Reconnect button.
- The main script bundle is 212 kilobytes gzipped, up from 201.
Upgrade notes
- The first start of 4.3 migrates
~/.dispatch/board.dbto schema 3. Before the migration changes anything, Dispatch writes a copy of the old file to~/.dispatch/board.db.pre-boards, and the same copy toboard.db.pre-v3. A folder with no cards, events or archived cards gets no copy. - If the copy or the migration fails, Dispatch does not start, and the error names the copy. A second start changes nothing.
- Every existing card, session, event and archived card lands on the default board, Local. LOCAL-n and GROUP-n ids, tmux session names, branches and worktrees stay the same. A session started on 4.2 keeps its tmux pane after the upgrade.
- A 4.2 build refuses a migrated folder and changes nothing. To return to 4.2, stop Dispatch, delete
board.db-walandboard.db-shmif they exist, copyboard.db.pre-boardsoverboard.db, and start 4.2. You lose every change made after the migration. - The chain settings live under
claudeAccountsinconfig.json. The chain state lives inchain-state.jsonnext toaccounts.json. - For contributors:
npm run checknow takes a lock, so two full checks on one machine run one after the other.npm run test:visualruns the Playwright suite.
See it
dispatch-v4.3.0-boards.mp4
Higher-quality video with narration: dispatch-v4.3.0-boards.mp4
Full changelog: v4.2.0...v4.3.0
Requires Node ≥ 22.22, tmux, ttyd, git, and the Claude Code CLI. Setup is in the README.
