# Using the command line

How to drive Kortix from a terminal with the kortix CLI.

Canonical page: https://kortix.com/docs/guides/using-the-cli

The `kortix` CLI does everything the dashboard does, from a terminal. It's optional — if you're not technical, use the dashboard instead.

## Install and log in

### Install the CLI

```sh
curl -fsSL https://kortix.com/install | bash
```

### Log in

```sh
kortix login
```

This opens your browser to authorize. Your token is then saved locally.

## The mental model

The CLI controls the same things as the dashboard: projects, [sessions](/docs/concepts/sessions), [secrets](/docs/guides/managing-secrets), [triggers](/docs/guides/automating-work), and [change requests](/docs/quickstart). It's the control plane, not a replacement for `git`.

## The most useful commands

Start a session, optionally with a first prompt:

```sh
kortix sessions new --prompt "Audit the auth module and propose a fix"
kortix sessions ls
```

Manage secrets:

```sh
kortix secrets set STRIPE_API_KEY=sk_live_...
kortix secrets ls
```

Push a local `.env`'s values up as secrets, or pull a names-only skeleton down:

```sh
kortix env push --from .env
kortix env pull
```

Work with triggers:

```sh
kortix triggers ls
kortix triggers fire daily-digest
```

Review and merge change requests:

```sh
kortix cr ls
kortix cr show 3
kortix cr merge 3
```

## Inside a session sandbox

Inside a session's environment the CLI is already authenticated for that project — no login needed. A project-scoped token is injected automatically, so commands like `kortix secrets ls` or `kortix cr open` work right away. This is how an agent opens its own change request.

> **Under the hood**
> On your laptop the CLI uses a user-scoped token (saved at `~/.config/kortix/config.json`) that can see every project on accounts you belong to. Inside a sandbox, `KORTIX_CLI_TOKEN` (falling back to `KORTIX_EXECUTOR_TOKEN`) is pre-injected and scoped to that one project. `KORTIX_TOKEN` is also present, but it's the sandbox's own service key, not a CLI credential — the CLI never uses it to authenticate. The CLI resolves "which project" from a flag, an env var, or a linked directory, in that order.