| name | kortix-cli |
| description | Drive Kortix itself from the terminal with the `kortix` CLI — preinstalled and pre-authenticated in every session sandbox. Use whenever a task means acting on THIS project's Kortix control plane rather than just editing files: manage secrets, list/spawn/watch/talk-to sessions, open or inspect change requests to land work on main, fire or manage triggers, call connectors, connect Slack, or read project info. This is a discovery stub — the full, always-current reference is served live via `kortix skills get kortix-system` and its reference files. |
kortix-cli
The kortix CLI is the control plane for Kortix — the same surface a human
drives in the dashboard, fully scriptable from a terminal. It is already
installed and pre-authenticated in every session sandbox: the binary is on
$PATH (/usr/local/bin/kortix), a project-scoped token (KORTIX_CLI_TOKEN)
and KORTIX_API_URL are pre-injected, so kortix … just works with no setup.
Start here
This file is a discovery stub, not the usage guide. The full, always-current
Kortix reference — every command, the manifest, change requests, the runtime — is
served live by the CLI, so it never goes stale between releases:
kortix skills
kortix skills get kortix-system
get prints the body and then lists the skill's reference files. Pull the
one you need instead of the whole tree — kortix-system is ~230 KB in full:
kortix skills file kortix-system references/kortix/kortix-cli.md
kortix skills file kortix-system references/kortix/kortix-yaml.md
kortix skills get kortix-system --full
Load kortix skills get kortix-system before doing anything non-trivial with
Kortix — the CLI serves version-matched content, which this static stub can't.
The complete kortix command reference is
references/kortix/kortix-cli.md inside kortix-system — not kortix skills get kortix-cli, which just returns this same stub.
The moves you'll reach for
kortix whoami
kortix secrets request <NAME>
kortix sessions status
kortix sessions new --json --wait --prompt "…"
kortix connectors call <connector> <action> '…'
kortix apps deploy . --slug <slug>
kortix cr open --title "…"
Coordinating sessions (spawn → wait → collect)
kortix sessions new --json --wait --with-file data.csv --prompt "…"
kortix sessions wait-for <id> --timeout 300
kortix sessions pending <id>
kortix sessions cp <id>:out/result.pdf .
- A finished session's sandbox stops automatically to save compute.
stopped means parked, not failed — sessions cp, sessions chat, and
sessions wait-for wake it on demand.
- Session ids abbreviate: any unambiguous prefix (the 8-char ids
sessions ls
prints) works.
- Session sandboxes have Python via uv (
uv run / uvx / uv pip —
prefer these over bare pip), Node, browsers, and document tooling
preinstalled — spawn the task, not an environment-setup plan.
Every read command takes --json (clean payload on stdout), so the CLI is a
100% scriptable surface. For anything beyond the above — flags, the token-scope
model, host switching, orchestration patterns — read
kortix skills file kortix-system references/kortix/kortix-cli.md (the full
command reference), or kortix skills get <name> for another system skill.
Landing work on main
A session runs on its own branch; the only sanctioned path to main is a
change request, and you open it — the user reviews and merges:
git add . && git commit -m "…" && git push origin HEAD
kortix cr open --title "…" --description "…"
Never merge your own CR. Full CR lifecycle: kortix skills get kortix-system.