CLI

Host Server

Set up the daemon the CLI and desktop app talk to when targeting the local machine.

The superset start command runs a headless HTTP server that any Superset desktop app or CLI can communicate with.

It manages workspaces, ports, and agent runs on the machine it's running on. The desktop app starts it automatically; on a CLI-only or headless machine you start it yourself.

If you installed the desktop app, it already includes the CLI and installs a ~/.superset/bin/superset shim on app launch. Superset terminals prepend that directory to PATH automatically. On a headless machine, use the standalone installer from Getting Started.

Prerequisites

git and gh need to be on your PATH. git handles clone, worktree, and branch ops; gh handles PR checkout and metadata.

gh auth login

The host server reuses your existing gh auth. For sandboxes or CI, set GH_TOKEN (or GITHUB_TOKEN) instead of running gh auth login. gh picks it up automatically.

Agent CLIs (optional)

If you plan to run AI agents inside workspaces, install whichever agent CLIs you want available. The host server launches them based on which are on your PATH:

AgentInstall
Claude Codenpm install -g @anthropic-ai/claude-code
Codexnpm install -g @openai/codex
Cursor Agentinstall via Cursor's website
Ampnpm install -g @sourcegraph/amp
Gemini CLInpm install -g @google/gemini-cli
OpenCodesee opencode.ai/docs

None are required to start the host server or create workspaces. Install only what you plan to run.

Authenticate the Superset CLI

The host server starts under your Superset session. If you haven't already:

superset auth login

See Getting Started for the full sign-in flow, including API-key auth for CI.

Start the host server

superset start --daemon

Spawns the daemon in the background and writes a manifest at ~/.superset/host/<organizationId>/manifest.json so other clients can find it. Binds to 127.0.0.1 only.

Verify it's healthy:

superset status

Keep it updated

Automatic updates are off by default. To turn them on, start the host with --auto-update:

superset start --daemon --auto-update
  • --auto-update requires --daemon.
  • The first check runs one hour after start, then every hour. A newer release installs, and the host restarts with its health check and rollback. Terminals reconnect after the restart.
  • Updates never downgrade the host. A release that fails its health check is skipped on later automatic checks; superset update can still install it.
  • The flag applies to a new start only. To change it, stop the host and start it again.

If an update fails with a permission error on superset.update-lock, the host user cannot write the directory that contains the install. The error names the install path, the lock path, and the user. Give that user ownership of the install and its parent directory, or reinstall as that user.

Run it under systemd

On a server, let systemd start the host server at boot and restart it on failure. Run superset start without --daemon so systemd tracks the process:

# /etc/systemd/system/superset-host.service
[Unit]
Description=Superset host server
After=network-online.target
Wants=network-online.target

[Service]
User=<user>
ExecStart=/home/<user>/superset/bin/superset start
Restart=on-failure
KillMode=process

[Install]
WantedBy=multi-user.target

Keep KillMode=process. Other kill modes stop the terminal daemon, and with it every terminal and agent, whenever the service stops or restarts. The terminal daemon keeps running after the service stops, so the next start picks up the same terminals.

This setup needs a CLI released after 1.30.2. With 1.30.2 and older, systemctl restart hangs until systemd kills the CLI, and the old host keeps running.

sudo systemctl daemon-reload
sudo systemctl enable --now superset-host

To end every terminal and agent too, stop the unit first, then stop the terminal daemon. If you run superset stop while the unit is active, systemd starts the host again.

sudo systemctl stop superset-host
superset stop --terminals

Getting started

Create or adopt a project

A workspace branches off a project: a repo registered with Superset.

Each repo gets one cloud project record, shared across the organization. The first machine to register the repo runs projects create; every machine after that uses projects setup to attach to the existing project instead of creating a duplicate.

Start by checking what's already in your org:

superset projects list

First machine: projects create

If the project doesn't exist yet, clone a remote repo or import an existing local one:

# Clone from a Git URL
superset projects create \
  --name "My Project" \
  --local \
  --clone https://github.com/org/repo.git \
  --parent-dir ~/code

# Or import a repo that's already on disk
superset projects create \
  --name "My Project" \
  --local \
  --import ~/code/existing-repo

The host server clones (or registers) the repo, creates the cloud project record, and ensures the main workspace.

Subsequent machines: projects setup <id>

If a previous machine of yours already created the project, adopt it instead of running create again: create would register a second, unrelated project for the same repo. Projects are host-owned, so pick the ID from a machine that has it (projects list --host <id>), then:

# Clone the project's repo onto this machine
superset projects setup 47c31b04-… --local --parent-dir ~/code

# Or attach to an existing local checkout
superset projects setup 47c31b04-… --local --import ~/code/repo

The URL for clone mode comes from the cloud project record, so setup doesn't need --clone <url>. setup is idempotent: re-running against a project that's already set up here is a no-op.

Create your first workspace

superset projects list
superset workspaces create \
  --project prj_… \
  --name "fix-login-bug" \
  --branch fix/login-bug

The host server clones the project (if it isn't already on disk), creates a git worktree at the chosen branch, and registers the workspace.

You can also create a workspace from a pull request number:

superset workspaces create \
  --project prj_… \
  --name "review-pr-123" \
  --pr 123 \
  --local

Stop the host server

superset stop

Your terminals and agents keep running in the terminal daemon, and the next superset start picks them up. To end them as well:

superset stop --terminals

Shared state

State lives under ~/.superset/host/<organizationId>/:

~/.superset/host/<organizationId>/manifest.json    # endpoint + auth token
~/.superset/host/<organizationId>/host.db          # local host server DB

A host server started by the desktop app is visible to the CLI and vice-versa. SUPERSET_HOME_DIR relocates the whole tree.

Command details

For full flags, exit codes, and output shapes: