Repository navigation
jus-dispatch v0.7.5
Installing jus-dispatch
⚠️ Dispatch is switched off (#3987). The server refuses dispatches, and every
control for them has been taken off the board, the phone and the marketing site. An
agent you already have installed will connect and then sit idle; a new install has
nothing to reach. This page is kept because it is the release notes for every
published build and the record of how the agent is set up — it is not an invitation
to install one.
jus-dispatch is the remote dispatch agent for Juscribe. It connects to the Juscribe server over a WebSocket, runs a coding-agent CLI against your project when a dispatch arrives, and reports the result back to the board.
Platform support: macOS and Linux, amd64 and arm64. Requires the CLI you dispatch to — Claude Code by default.
Install
brew install juscribe/tap/jusThat installs the jus CLI and jus-dispatch together, and brew upgrade jus moves both. Binaries for macOS and Linux, amd64 and arm64, are attached to every release at github.com/juscribe/jus-dispatch/releases and download without authentication.
--sandbox docker mode that no longer exists — jus-dispatch runs the CLI on the host.
To build from a checkout instead:
cd dispatch && make buildThat writes dispatch/bin/jus-dispatch. make build-all cross-compiles all four platforms into the same directory, and make install copies the host build into $GOPATH/bin.
What it does NOT do
The station created a git worktree per dispatch, ran the CLI inside it, and then merged, pushed or left the branch. jus-dispatch does none of that. It runs the CLI in the project checkout itself and reports what came back:
- no worktree, no branch, no merge, no push;
- no sandbox to choose — the station's
raw/orbstack/dockermodes and theirsetup-orb,setup-docker,setup-sandboxandauthcommands all stayed behind at the tag; branch_strategyno longer arrives on the wire at all (#3902), and was read by nothing here even while it did.
#3900 is where the read-only contract is enforced rather than merely true by construction.
.claude/settings.json (#3970). Measured on claude 2.1.267: a project's own permission rules override the --permission-mode dontAsk and --allowedTools flags the agent passes, so a dispatch running there can write files with the Write tool. Every operator's checkout is a trusted one, because that is where they use Claude Code — so this is the normal case rather than an edge one. It is a large part of why the feature is off.
Setup
jus-dispatch initPress Enter to accept a default (shown in brackets):
| Prompt | Default | What it means |
|---|---|---|
| API token | (none — required) | Your Juscribe API token, from Settings → API Tokens. It authenticates the agent with the server. |
| Server URL | wss://app.juscribe.ai/cable |
The WebSocket endpoint for your Juscribe instance. Accept the default unless you have a designated subdomain. |
| Project path | Current directory | Absolute path to the git repository the agent runs in. |
| CLI provider | claude |
Only shown when multi-LLM is enabled for your workspace. |
| Thinking effort | medium |
low, medium, high or max. Claude only. |
| Log level | info |
debug, info, warn or error. Use debug when troubleshooting a connection. |
| Log file | ~/.local/share/jus-dispatch/logs/jus-dispatch.log |
Where the structured log is written, in addition to stderr. |
Config is saved to ~/.config/jus-dispatch/config.toml, or to <project>/.jus/dispatch.toml when the directory has been through jus init.
~/.config/jus-station/ is not read, at any precedence. A frozen station and a new agent can sit on one machine, and sharing a config would have each writing over the other's scope. The station cannot connect either way — #3900 raised the server's protocol floor past it — but the file is left alone rather than migrated.
Every value can be overridden at runtime by a flag (--token, --server, --project, --log-level, --log-file) or an environment variable (JUSCRIBE_API_TOKEN, JUS_SERVER_URL, JUS_PROJECT_PATH, JUS_LOG_LEVEL, JUS_LOG_FILE, JUS_EFFORT_LEVEL).
Usage
jus-dispatch startThe agent connects to your workspace and listens. When a dispatch arrives it:
- claims it, and runs only if the server grants the claim;
- spawns the CLI in the project checkout with the ticket prompt;
- streams heartbeats and status back to the workspace in real time;
- reports the result when the session ends.
Leave it running in a terminal tab, a tmux session or behind a process manager. Ctrl+C shuts it down gracefully — it holds the connection open until active dispatches finish, and a second Ctrl+C quits immediately.
A result nothing could deliver is spooled under ~/.local/share/jus-dispatch/spool and re-sent at the next start.
Other commands
| Command | Description |
|---|---|
jus-dispatch version |
Print agent and protocol versions |
jus-dispatch init |
Re-run the setup wizard (overwrites the existing config) |
Verify
Check the Juscribe workspace — the header shows a green agent indicator. With one agent connected it is a dot; with several it becomes a count badge, and hovering names them. Dispatches route to your agent when the workspace dispatch mode is set to "agent".
Configuration file
[server]
url = "wss://app.juscribe.ai/cable"
token = "your-bot-api-token"
organization_id = "org-uuid"
workspace_id = "1"
[project]
path = "/path/to/your/project"
[execution]
cli_type = "claude"
claude_path = "claude"
max_turns = 200
heartbeat_interval = "30s"
effort_level = "medium"
[logging]
level = "info"
file = "/Users/you/.local/share/jus-dispatch/logs/jus-dispatch.log"The file is written 0600 — it holds the API token.
Troubleshooting
"subscription rejected by server" — the protocol version is too old (brew upgrade jus) or the token does not belong to a bot user. Both are deterministic: the agent gives up rather than retrying.
"registered with NO workspace" — the agent is connected but invisible. Scope its API token to a workspace, or set organization_id / workspace_id under [server].
"registration rejected" — the workspace may have moved to an organization you are not a member of. Ask an owner to invite you, then set the ids above and restart.
"dispatch.toml holds a token that is NOT in use" — the injected JUSCRIBE_API_TOKEN overrides the file's. Clear the stored one so it cannot misdirect the next debugging session.
Dispatches fail in ~250 ms having burned no tokens — the CLI cannot authenticate. Sign it in again; the log says so at error level with the CLI's own reason.