Skip to content

jus-dispatch v0.7.5

Choose a tag to compare

@caleon caleon released this 12 Sep 02:58
· 3 commits to main since this release
356c096

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/jus

That 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.

⚠️ There is no container image, and that is deliberate (#3912). The station published one, for a --sandbox docker mode that no longer exists — jus-dispatch runs the CLI on the host.

To build from a checkout instead:

cd dispatch && make build

That 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 / docker modes and their setup-orb, setup-docker, setup-sandbox and auth commands all stayed behind at the tag;
  • branch_strategy no 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.

⚠️ The read-only contract does NOT hold in a checkout that carries its own .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 init

Press 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 start

The agent connects to your workspace and listens. When a dispatch arrives it:

  1. claims it, and runs only if the server grants the claim;
  2. spawns the CLI in the project checkout with the ticket prompt;
  3. streams heartbeats and status back to the workspace in real time;
  4. 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.