CLI

Install the Auto Lab command line, sign in, and work with your goals, sessions and change requests from a terminal.

The Auto Lab CLI lets you work on your goals from a terminal. You can clone a goal's repository, ship changes, review change requests, set secrets and call connectors. The command is kortix, and the goal's own agents use the same command inside their sandboxes.

Install

curl -fsSL https://app.auto-lab.ai/install | bash

The installer runs on macOS and Linux, on x64 and arm64 machines. Windows is not supported. It saves the program in ~/.kortix and links it onto your PATH, in /usr/local/bin or ~/.local/bin.

The download page shows whether a CLI release is published and which version it is. Until a release exists, the install command does not work.

Sign in

kortix login

1. Your browser opens Sign in to the Auto Lab CLI at app.auto-lab.ai/cli/authorize. Sign in to Auto Lab first if you are asked to.
2. Check the email and device shown, then select Authorize.
3. Back in the terminal, pick your active organization if you belong to more than one, then pick a default goal.

Authorizing creates a personal access key named after your device, such as "CLI · my-laptop". The key acts as you, with exactly your permissions. It is listed in Personal settings › Personal access keys, where you can revoke it. The CLI stores it in ~/.config/kortix/config.json, readable only by you.

On a server or in CI, where no browser can open, create a personal access key and pass it in:

kortix login --token "$AUTOLAB_API_KEY" --account "$ACCOUNT_ID" --no-project

kortix whoami shows who you are signed in as and which organization is active. kortix logout forgets the key on this machine. It does not revoke the key, so revoke it in Personal settings when you no longer need it.

Names the CLI uses

The CLI uses the API's names. It calls a goal a project and an organization an account. So kortix projects ls lists your goals, and kortix accounts use switches organization.

A session is a workbench: an isolated sandbox on its own branch. A coder task opens one, and older goals do all their work in sessions. The goal's Chat is not a session, and the CLI has no command for it. Talk to the goal in Auto Lab or in its channel.

A command that acts on one goal picks it in this order: the --project <id> flag, the goal the current folder is linked to (.kortix/link.json), then your default goal.

Goals

kortix projects ls
kortix projects clone 3f2a9c1e-5b7d-4e8a-9c0f-1d2e3f4a5b6c weekly-brief

Clone goes through Auto Lab with your sign-in, whether the repository is managed by Auto Lab or lives on GitHub. It also sets up the folder so plain git pull and git push use your sign-in. You need no separate git credentials. See The goal's repository for what is inside.

Change files and ship them

Edit a cloned goal like any git repository, then ship your work:

git switch -c tidy-outreach-skill
kortix ship -m "Tidy the outreach skill"
kortix cr open --head tidy-outreach-skill --title "Tidy the outreach skill"

kortix ship checks the goal manifest, commits any changes, and pushes your current branch to the same branch on the goal's repository. Along the way it asks for any secret or connector the manifest needs and does not have yet. Use -n to see what it would do without doing it.

Work on a branch and open a change request, so your change is reviewed the same way as the agents' changes. Pushing straight to main also works when your role lets you push.

kortix init --force, run inside a cloned goal, adds the files that let local coding tools (Codex, Claude Code, Cursor, OpenCode, Pi) read the goal's agents and skills. It does not change how the goal runs in Auto Lab.

Start new goals in Auto Lab

Create a goal with New goal in the web app, so its agent can set it up with you. Running kortix ship in a folder that is not linked to a goal creates a new goal from that folder, without the setup conversation.

Sessions

kortix sessions ls
kortix sessions new --prompt "Add a test for the lead scoring script" --wait

Change requests and review

A change request proposes merging one branch into another, usually a session's branch into main. <cr> is the change request's number or ID.

kortix cr diff 12
kortix cr merge 12

Secrets

printf '%s' "$HUBSPOT_TOKEN" | kortix secrets set HUBSPOT_TOKEN=-

See Secrets for how values reach the agents.

Connectors

kortix connectors discover "find unread email from customers"

discover returns the matching tools as JSON, each named <slug>.<action>. kortix connectors show <slug>.<action> shows the arguments a tool takes. Pass the name to call, with the arguments as JSON. A call runs server-side, with the goal's connection and its tool rules. The CLI never holds the tool's credentials. When a rule says ask first, the call returns an approval link instead of running. See Connectors.

Triggers, channels and models

Triggers here are the ones declared in the manifest. The agent's own reminders, check-ups and routines are in Brain › Schedules. See Plans, schedules and triggers, Channels and Models.

Access

Goal roles are manager (shown as Project admin) and member (Project member). Organization roles are owner, admin and member. See Roles and access.

When an agent uses the CLI

The goal's agents run the same kortix command inside their sandboxes:

• They do not sign in. The sandbox gives them a token bound to that goal and session, so commands act on that goal without a link file.
• An agent can never do more than the person its work runs for. If the goal manifest limits an agent's kortix_cli commands, it is held to that list too.
• A session can push only to its own branch, so its work reaches main through a change request.
• Agents learn the platform with kortix system-skills.

See The goal's repository.

Help and exit codes

Every command has --help, for example kortix cr --help. kortix --help lists every command.