# CLI: Install & sign in

Install the CLI, sign in and connect your first repository.

## Install

Install the CLI, which includes the MCP server, with one line:

```bash
curl -fsSL https://bumpkit.dev/install.sh | sh
```

The script downloads the archive for your platform, checks its SHA-256 against `checksums.txt`, unpacks it and runs `bumpkit install --yes`. Set `BUMPKIT_INSTALL_DIR` to choose the directory. `BUMPKIT_VERSION=v1.4.2` pins the install to that release and fails unless it's the latest; only the latest release is available.

To install by hand, download the archive and `checksums.txt`, verify, unpack and install:

```bash
curl -fsSLO https://bumpkit.dev/download/latest/bumpkit_darwin_arm64.tar.gz
curl -fsSLO https://bumpkit.dev/download/latest/checksums.txt
grep " bumpkit_darwin_arm64.tar.gz$" checksums.txt | shasum -a 256 -c
tar -xzf bumpkit_darwin_arm64.tar.gz
./bumpkit install
```

Archives are named `bumpkit_<os>_<arch>.tar.gz` for `linux`, `darwin` and `windows` on `amd64` and `arm64`. On Linux, use `sha256sum -c` in place of `shasum -a 256 -c`. Check what you installed with:

```bash
bumpkit --version
```

### bumpkit install

Copy this `bumpkit` into a directory on your `PATH`, then run `bumpkit version` from there to check the install. It then prints the next steps, including `claude mcp add --transport http bumpkit https://bumpkit.dev/mcp` and `bumpkit mcp config` for connecting an MCP client.

```bash
bumpkit install [--user | --system | --dir DIR] [--yes]
```

By default it installs for everyone, in `/usr/local/bin` (or `/opt/homebrew/bin` on Apple Silicon Macs with Homebrew), which is already on `PATH`. When that directory isn't writable, it says so and runs only the copy with `sudo`, after asking. On Windows it installs in `%ProgramFiles%\Bumpkit` from an elevated terminal and adds it to the machine `PATH`.

With `--user`, or when `sudo` isn't available or you decline it, it installs in `~/.local/bin` (`%LOCALAPPDATA%\Programs\Bumpkit` on Windows) and, if that directory isn't on `PATH`, adds it for the shell you use, once:

| Shell | File | Line |
|-------|------|------|
| zsh | `${ZDOTDIR:-~}/.zshrc` | `export PATH="DIR:$PATH"` |
| bash | `~/.bashrc`; on macOS `~/.bash_profile`, unless it already sources `~/.bashrc` | `export PATH="DIR:$PATH"` |
| fish | `~/.config/fish/conf.d/bumpkit.fish` | `fish_add_path --path "DIR"` |
| sh, dash, ksh | `~/.profile` | `export PATH="DIR:$PATH"` |
| tcsh, csh | `~/.tcshrc` if it exists, else `~/.cshrc` | `set path = ("DIR" $path)` |
| PowerShell | your `$PROFILE` | `$env:PATH = "DIR" + [System.IO.Path]::PathSeparator + $env:PATH` |

For nushell and elvish, and when a file can't be edited, it prints the exact line to add instead. It also installs tab completion for bash and fish.

| Flag | Default | Meaning |
|------|---------|---------|
| `--user` | `false` | Install for this user only, in `~/.local/bin` |
| `--system` | `false` | Install for everyone (the default) |
| `--dir` | | Install into this directory |
| `--yes`, `-y` | `false` | Don't ask before using `sudo` or editing shell startup files |

### bumpkit update

Download the latest release from `https://bumpkit.dev/download`, check its SHA-256 against that release's `checksums.txt` (which catches a corrupted or incomplete download), and install it over the running `bumpkit`, using `sudo` when that directory needs it.

| Flag | Default | Meaning |
|------|---------|---------|
| `--force` | `false` | Reinstall even when this is already the latest version |
| `--wait` | `false` | When a newer release is still building, check every 15 seconds for up to 20 minutes and install it as soon as it's ready |
| `--yes`, `-y` | `false` | Don't ask before using `sudo` |

New releases ship automatically whenever the CLI or its MCP server changes. A release is downloadable once every platform's binary and its checksums are ready, a few minutes after it's published. Until then `bumpkit update` says so instead of claiming you're current:

```text
… v0.94.0 was published 2 minutes ago and its binaries are still building. Run bumpkit update again in a few minutes, or bumpkit update --wait to install it as soon as it's ready.
```

You don't have to check: every response from the Bumpkit API carries the latest version, and when yours is behind, `bumpkit` prints one line to stderr, at most once an hour, and right away when a newer release lands:

```text
bumpkit v0.91.0 is out of date; v0.93.0 is live. Run: bumpkit update
```

While a newer release is still building, you get `bumpkit v0.94.0 is on its way; its binaries are still building. Run bumpkit update in a few minutes.` instead, at most once an hour.

The line never appears with `--json`, or when stdout or stderr isn't a terminal, so scripts and CI logs stay clean. `bumpkit mcp` tells your agent the same thing when it connects. The dashboard's CLI and MCP modes show only the commands and tools in the latest release; anything newer is marked as coming in the next CLI release.

### bumpkit uninstall

Remove `bumpkit` from the directory the running `bumpkit` is in, and the tab completion it installed, then offer to remove the `PATH` line the installer added.

| Flag | Default | Meaning |
|------|---------|---------|
| `--yes`, `-y` | `false` | Don't ask before using `sudo` or editing shell startup files |

## Connect a repository from a new CLI session

```bash
bumpkit login
bumpkit whoami --json
```

Sign in on the browser approval page, choose the workspace you want to connect and approve the matching terminal code. The CLI key belongs to that selected workspace. `whoami --json` reports its name and ID. To land in a specific workspace, run `bumpkit login --workspace UUID`, which preselects it on the approval page and keeps the key only if it belongs there. `bumpkit workspace list` shows every workspace you belong to, and `bumpkit workspace switch NAME_OR_ID` signs this computer in to another one the same way.

```bash
bumpkit repo list
bumpkit repo add
```

`repo list` shows repositories authorized by the current workspace's GitHub App installations. `repo add` opens browser authorization when access is needed. Sign in as the same Bumpkit user and workspace, select the GitHub account or organization and grant the App access to the intended repositories. An organization may require its administrator to approve the installation. Return to the terminal, choose a repository from the authorized list and wait for verification. Bumpkit checks installation ownership and reads the default branch; merely opening the consent page does not connect a repository.

To select this example repository explicitly:

```bash
bumpkit repo add acme/shop
bumpkit repo verify acme/shop
bumpkit repo pulls list acme/shop --limit 50 --json
```

Use a repository you own or can administer. In a headless terminal, append `--no-browser` to `repo add` and open its printed authorization URL yourself. Existing access is reused, and verification does not change the repository. The Repository dashboard generates these commands with its actual workspace ID guard.

Choose a real pull request number from the output before running `bumpkit github check` for it. This runs and records a release check and publishes its GitHub result; it does not merge or deploy. If there are no open pull requests, create one in the repository before requesting a check.

## Discover open pull requests in a connected repository

```bash
bumpkit repo pulls list acme/shop
bumpkit repo pulls list acme/shop --limit 50 --json
```

This reads the actual open pull requests for the selected repository through this workspace's GitHub App. It uses the same repository visibility, installation ownership and oldest-created-first ordering as the connected PR page. The default and maximum limit are 50; `--limit` accepts 1–50. Human output includes PR number, title, author, draft state and head/base branches. JSON also includes the head commit SHA and workspace identity.

A person-bound key and GitHub App access are required; workspace viewers can list. The repository must be selected in an installation linked to the current workspace. Listing does not run checks, save release decisions or post to GitHub. After choosing an actual PR number, explicitly run `bumpkit github check NUMBER --repository acme/shop` to request its release check.

## bumpkit login

Sign in by approving this computer in your browser. The CLI then gets its own API key for your workspace, saved in the [config file](/docs/cli-flags#sign-in-and-config-file), and prints the workspace it signed in to. Pass `--workspace UUID` to preselect a workspace on the approval page; the key is kept only if it belongs to that workspace. On a machine without a browser, pass `--no-browser` and open the link anywhere, or pipe an existing key in with `--with-token`.

| Flag | Default | Description |
|------|---------|-------------|
| `--no-browser` | `false` | Print the approval link instead of opening a browser |
| `--with-token` | `false` | Read an API key from standard input instead of using the browser |

```bash
echo "$BUMPKIT_API_KEY" | bumpkit login --with-token
```

## bumpkit logout

Sign out and revoke this computer's API key. If you signed in with `BUMPKIT_API_KEY` from your environment, unset it instead.

| Flag | Default | Description |
|------|---------|-------------|
| `--keep-key` | `false` | Sign out locally but leave the API key active |

## bumpkit whoami

Show the workspace, user, key and API URL this CLI is using. `--json` also includes the workspace ID and plan.

```bash
bumpkit whoami --json
```

## bumpkit workspace

List, create, switch and delete workspaces. An API key belongs to one workspace, so `switch` approves a new key in your browser with the chosen workspace preselected, the same as `bumpkit login --workspace UUID`.

```bash
bumpkit workspace list
bumpkit workspace switch "Acme Demo"
bumpkit workspace create "Acme Demo"
```

Add `--switch` to `create` to sign this computer in to the new workspace right away. Deleting a workspace takes its owner signed in to the dashboard: `bumpkit workspace delete` gets a refusal saying where to do it. It permanently deletes the workspace and its data. People keep their accounts and their other workspaces.

## bumpkit account link-github

Show whether your Bumpkit login is linked to a GitHub account. Approvals are matched to approvers by GitHub account, so a vote from a login without one is refused. When it isn't linked, the command opens the dashboard page that connects GitHub to the login you're signed in with. `--no-browser` prints the link instead, and `--json` prints the link status.

```bash
bumpkit account link-github
```

## bumpkit features

List the features turned on for your workspace.

```text
bumpkit features [flags]
```

| Subcommand | Usage | Description |
|------------|-------|-------------|
| `request` | `bumpkit features request FEATURE` | Ask for early access to a Beta feature for your workspace |

`FEATURE` is the feature's flag, such as `release_trains`. You can request any Beta feature your workspace doesn't have yet. Any role that can make changes can ask; viewers and auditors get `403 FORBIDDEN`. Asking twice is safe: the second request reports `created: false` in `--json` output. You can send 10 requests a minute; past that you get `429 RATE_LIMIT_EXCEEDED`. A feature that's already on, isn't in Beta or doesn't exist returns `404 NOT_FOUND`.

```text
bumpkit features request release_trains
```

## bumpkit onboarding

Check and finish your workspace's first-run steps from the terminal. They match the checklist on the dashboard's overview.

| Subcommand | Usage | Description |
|------------|-------|-------------|
| `view` | `bumpkit onboarding view` | Show the workspace, whether its name is confirmed, whether the GitHub App is installed, whether a release decision came in and whether the checklist is dismissed |
| `confirm` | `bumpkit onboarding confirm --workspace-id UUID --name NAME` | Save the workspace name and finish the naming step |
| `dismiss` | `bumpkit onboarding dismiss --workspace-id UUID` | Hide the first-run checklist for everyone in the workspace |

Anyone in the workspace can run `view`. Only owners and admins can run `confirm` and `dismiss`. Both need `--workspace-id`, and it must match the workspace your key signs in to, so you can't change the wrong one by mistake. Run `bumpkit whoami` to see it. The name can be up to 64 characters. `dismiss` also needs the explanations feature (flag `explanations`) on for your workspace. Both changes are written to the audit log.

```bash
bumpkit onboarding view
```