CLI reference

Subcommand reference

Every snaga subcommand, what it is for, and which ones only read.

snaga <subcommand> --help is authoritative on your machine. This page is for finding the one you want.

Account

`snaga login`	Sign in — email one-time code, or an API token starting `uarp_`
`snaga whoami`	The account, organisation and plan this machine is using
`snaga logout`	Remove saved credentials
`snaga update`	Update to the latest version

Connecting

`snaga connect`	Link this machine so the web and mobile apps can run tasks here — see Run tasks from your phone
`snaga mcp-server`	Expose the tool registry as an MCP server over stdio, so other agents and editors can call Snaga's tools

Sessions

`snaga sessions list`	One line per session: id, start, message count, opening request
`snaga sessions show <id>`	Print a transcript
`snaga sessions fork <id>`	Copy a session to a new id, leaving the original alone
`snaga tail <session-id>`	Follow a session's structured event log live, from another terminal, without attaching to the process

tail is the one to use while an autonomous run is working: it reads the event log and follows it, so you can watch without interrupting.

Tools from the registry

`snaga spec search <query>`	Search the registry
`snaga spec info <name>`	Metadata for one SPEC
`snaga spec install <name>`	Install, or re-sync from the lockfile
`snaga spec list`	What is installed locally
`snaga spec update`	Move to newest allowed versions
`snaga spec init`	Scaffold a SPEC project here
`snaga spec build`	Build a bundle locally, without publishing
`snaga spec publish`	Build and publish
`snaga spec share`	Manage who can see a private SPEC
`snaga spec yank` / `unyank`	Withdraw or restore a version you own

See Installing tools from the registry.

Permissions

`snaga permissions policy`	Long-term rules in `~/.config/snaga/permissions.toml`
`snaga permissions audit`	The append-only grant log at `~/.snaga/audit/grants.log`

Session grants live in memory — use /permissions in the REPL for those.

Autonomous runs

`snaga autonomy list`	Persisted runs with their progress; ones with pending work can be resumed
`snaga autonomy reflect <goal>`	Cross-session report for a goal: run count, outcome tally, trajectory, SPECs installed previously
`snaga eval list`	Most-recent runs across all goals
`snaga eval show <goal_id>`	Every stored run for one goal, newest first
`snaga eval baseline freeze <label>`	Snapshot the current state under a label
`snaga eval baseline diff <label>`	Per-goal Regression / Improvement / Stable since that baseline

eval show answers "did that install actually help?" — compare the outcome column against the tools present at each run's start.

Everything here reads, except baseline freeze.

Maintenance

`snaga selftest`	Fast subsystem probes; exits 0 when all pass. Intended as a post-install gate
`snaga eval prune`	Delete run rows older than a cutoff. The latest run of every goal is always kept, so reflection keeps working; baselines are never touched
`snaga history prune`	Trim the SPEC install ledger. Anything touching a currently-installed SPEC is preserved regardless of age, or rollback would lose track of what to revert
`snaga rollback <session-id>`	Reverse a session's recorded side-effects

snaga rollback reverses what can be reversed — file writes, SPEC installs, WASM tool creations — and surfaces the rest for you: shell runs and remote HTTP mutations are listed for review rather than silently "undone", because nothing can honestly claim to un-send a request.

Both prune commands preserve what something else still depends on. That is the pattern worth noticing before you write your own cleanup: age is not the only thing that decides whether a row is garbage.