CLI reference

The arise CLI drives everything the dashboard can, from a terminal — laptop, coding agent, or session sandbox. For common workflows, see Using the CLI.

Always available inside a session sandbox, no setup:

• Binary on PATH (/usr/local/bin/arise).
• ARISE_CLI_TOKEN pre-injected — the project-scoped token the CLI authenticates with. (ARISE_TOKEN is also present, but it's the sandbox service key, not a CLI token.)
• ARISE_API_URL points at the platform you're running against.

Quickstart inside a session

arise whoami                       # confirms what project + account this token has
arise projects info                # the project you're running inside
arise secrets ls                   # encrypted env vars + manifest [env] spec
arise sessions ls                  # every session on this project (incl. you)
arise cr ls                        # open change requests
arise cr open --title "..."        # propose merging your branch into main

The sandbox token is project-scoped: read+write anything on this project (secrets, sessions, triggers, change requests, apps), but it can't list other projects or touch account-level resources. See Token scope.

On your laptop

curl -fsSL https://arise.sa/install | bash
arise login                        # opens browser, you click Authorize

The local CLI uses a user-scoped token at ~/.config/arise/config.json (mode 0600), which sees every project on every account you're a member of.

Command surface

Auth

Hosts

A host is one Arise API endpoint. The built-ins cloud (Arise Cloud), selfhost (your arise self-host stack), local-dev (a local pnpm dev server), and arise-internal-dev are always available, and you can add more endpoints. One host is active at a time; the CLI prints the active host before operational commands so Cloud/local actions are harder to mix up.

--host <name> overrides the active host for one invocation: arise projects ls --host local.

Self-host

arise self-host start creates and starts a production-style local Arise stack using Docker Compose. On first interactive setup it only asks for the product integrations you may need: Freestyle for app deployments, a GitHub App or PAT for repo access, and Pipedream for app connectors. Local ports, Supabase, generated secrets, and Docker defaults are handled automatically.

Projects

How a command finds "the project"

In strict order:

1. --project <id> flag.
2. ARISE_PROJECT_ID env var.
3. .arise/link.json in cwd (or any ancestor — git-style).
4. Inside a session sandbox: the sandbox's own ARISE_PROJECT_ID.

If none resolve, the command errors pointing to projects link.

How a command finds "the host"

1. --host <name> flag.
2. host field in .arise/link.json (so a repo always hits its home Arise instance).
3. The globally-active host.

Secrets

Encrypted env vars stored on the project, injected as plain env into every session sandbox at boot.

Env — dotenv ↔ secrets

Sessions

Each session is an isolated sandbox VM on its own ephemeral branch.

Inside a sandbox, ARISE_SESSION_ID is your session; arise sessions info $ARISE_SESSION_ID is the live view of yourself.

Triggers

Round-trip through arise.toml's [[triggers]]; the dashboard sees the same state.

Change requests (cr)

Arise-native PR layer for session work landing on main — merges one branch (head_ref) into another (base_ref) on any git host, no per-host integration. The only sanctioned way for an agent to land session-branch work on main. See Change requests.

<cr> accepts the short per-project number (3, #3) or the full UUID cr_id. Numbers are unique per project, monotonically increasing.

Inside a sandbox — the typical agent flow

# 1. Commit on the session branch
git add .
git commit -m "Add release-notes skill"

# 2. Push the branch (ARISE_BRANCH_NAME)
git push origin HEAD

# 3. Open the CR — head and session are auto-detected
arise cr open \
  --title  "Add release-notes skill" \
  --description "Drafts release notes from merged commits. Tested against the last 5 tags."

# 4. Confirm it's listed
arise cr ls

# 5. (Optional) show the diff one more time
arise cr diff 3

The agent does not merge its own CR — that's the user's call, in the dashboard or via arise cr merge <n>.

Install / update / uninstall

Project scaffold

Other commands: ship (alias deploy) pushes your local commits to the project's cloud repo, provisioning a managed repo on first run — despite the alias, it's a git push, not app deployment. channels connects Slack to a project. Run arise help for the full list.

Token scope

Two token types, both with the arise_pat_… prefix, distinguished by an internal project_id column on the token row.

Enforcement: every project route checks the token's project_id against the URL's :projectId. Mismatch → 403. Account routes (/v1/accounts/*) reject any project-scoped token outright.

Inside a sandbox

The session bootstrap injects (among other runtime vars):

ARISE_CLI_TOKEN=…          # project-scoped PAT — the CLI authenticates with this
ARISE_TOKEN=…              # sandbox service key (daemon control surface) — NOT a CLI token
ARISE_API_URL=https://api.arise.sa
ARISE_PROJECT_ID=<uuid>
ARISE_SESSION_ID=<uuid>

The CLI reads ARISE_CLI_TOKEN automatically (falling back to ARISE_EXECUTOR_TOKEN, the same value) and uses ARISE_API_URL as the host base. No config file needed. Don't reach for ARISE_TOKEN — it's the daemon's service key, and the project-scoped API routes the CLI hits reject it.

Rotating

A sandbox's project token is minted at session create and lives for that sandbox. Restarting re-provisions and issues a fresh token; an existing sandbox keeps its token until it restarts.

Common workflows

Spin up a fresh session with custom env

arise secrets set OPENAI_API_KEY=sk-… ANTHROPIC_API_KEY=sk-…
arise sessions new --prompt "Audit the auth module and propose a fix"

Inside a session: trigger another session

arise sessions new --prompt "Verify migration 0048 by running pnpm test + opening a CR if anything fails"

Run a trigger by hand for debugging

arise triggers ls                      # confirm the slug + status
arise triggers fire daily-digest       # one-shot manual fire
arise sessions ls | head -3            # the new session that the trigger spawned

Pull current secrets into a local .env for development

arise env pull                         # names only, values left blank
$EDITOR .env                            # fill in values locally
# (don't push — local-only file)

Bulk-upload local .env to the cloud project

arise env push --from .env
arise secrets ls                       # confirm

Land session work on main (the CR flow)

The agent opens the CR; the user reviews and merges. No other path to main from inside a session.

# inside a session sandbox, on branch session-<id>
git add .
git commit -m "Add release-notes skill"
git push origin HEAD

arise cr open \
  --title       "Add release-notes skill" \
  --description "Drafts release notes from merged commits. Tested against the last 5 tags."

arise cr ls                            # confirm

The user then runs arise cr show 3, arise cr diff 3, and arise cr merge 3 (or arise cr close 3).

Environment variables the CLI reads

The ARISE_* prefix is reserved for platform-injected values. Don't declare project secrets with it — the secrets-manager API rejects them and the manifest validator warns.

Exit codes

What the CLI is not

• Not a separate runtime. Use arise self-host start to run your own local Arise Cloud stack, then switch between Cloud and local APIs with arise hosts use.
• Not a git replacement. arise cr composes with git rather than wrapping it.
• Not the runtime. OpenCode executes the agent in the sandbox; the CLI is the control plane. See Arise vs OpenCode config.