Reference

CLI commands

The borg executable ships in the borgmcp npm package. Always use the installed client's help as the exact reference for your version. Borg launches your selected coding agent; when the current worktree has a saved Borg connection, the session reconnects to that cube. See the launcher explanation and --cli choices.

borg --help
borg <command> --help

Client lifecycle commands

• borg quickstart creates the repository's cube, adds one drone for every role in the template, and launches all of their sessions — the fastest path from a repository to a staffed cube. For a new cube it prompts for the template; --template <name> chooses it without prompting and --role <slug>[:<count>] replaces the default roster with exactly the roles you name. It requires a running Borg server and never starts one, and a rerun after a partial failure keeps and skips the drones that already exist. See Get started for the full setup sequence.
• borg clone <repository-url> [directory] clones a repository and then runs quickstart inside the new checkout. --checkout-only stops once the checkout is ready. A repeated command reuses an existing checkout only when its origin matches, and credential-bearing URLs are refused — use a Git credential helper or SSH configuration instead.
• borg assimilate adds one drone to your Git repository and launches its coding agent already connected to the repository's cube. Each drone gets its own worktree and branch under ~/.borg/worktrees/<repo>/<name>. Borg names the worktree after the drone's role; pass --worktree <name> to set the name yourself. borg assimilate --here resumes the drone saved in the current worktree instead of creating a new one. Use it to add a drone after quickstart, or to fill a role quickstart left out.
• borg launches the selected agent CLI. In a drone's worktree, it resumes that worktree's saved cube connection directly, without a menu. In an interactive terminal at the repository root, it shows a menu of the repository's drones available to resume so you can pick one; a drone is offered only when its saved connection is active and its worktree is still on disk.
• borg update updates the Borg client and its local server together, as a compatible published pair; it does not restart running agent sessions, so restart those yourself.
• borg doctor inspects Borg agent integrations without changing them, and reports a repair command when a check fails.
• borg cleanup reports orphaned Borg-managed worktrees.
• borg drones lists the drones registered on this machine, with each drone's cube, worktree path, agent CLI, and state. The registry belongs to this machine only.
• borg launch <drone-label-or-id-prefix> reopens one active drone from any directory. Borg finds the drone's worktree in the local registry and starts it exactly as if you ran borg in that worktree. If the drone is not active, or its worktree is missing, Borg refuses and tells you how to recover. When the same label exists in more than one cube, add --cube <name> or use the drone id prefix.
• borg launch-all [cube] opens the cube's saved drone worktrees; assimilate at least one drone first. In an interactive terminal on macOS with iTerm2 or Terminal.app installed, each drone opens in its own terminal tab or window, titled with the drone's name; on Linux the drones share one tmux session; with neither available, Borg prints the launch commands for you to run. --mode <tmux|terminals|pastelist> selects the backend explicitly.

Worktree maintenance

borg cleanup reports orphaned Borg worktrees by default. The --prune option performs the removal only when explicitly requested.

borg cleanup
borg cleanup --prune

Server and tools

See Get started for the local server sequence and server operations for private-LAN configuration. For in-session tools, use the tool reference.