Skip to the page
orbslateOpen the console
← All docs

The command line

slate is the agent: the program that runs inside your network, holds every secret and runs every tool. It runs a tool only once this machine is paired with a workspace. Before that it answers these, and connect:

  • slate doctor checks this machine: the agent's home is private to you (0700, its files 0600), the keyring that will keep your secrets works (it names which one and stores, reads back and deletes a test entry), the service answers as itself, and this machine's clock is within 5 minutes of it. A red line says what to do. Add --json for a script.
  • slate status says the version, where the agent keeps its files, the workspace it is paired with, its licence, and how many connections it has. Add --check to ask the service about the licence now rather than use the one checked today.
  • slate login pairs this machine. It prints a code and opens the console. Sign in there, check that the code matches, and choose Pair this agent. The agent then acts in that workspace with your role. Its token goes to the keyring, never to a file you could paste from, and it fetches its licence and policy at once. --no-browser prints the address without opening it, for a server.
  • slate logout forgets the pairing on this machine: the token, the licence and the policy. Revoke the agent in Agents too, if the machine is gone for good.
  • slate mcp is the MCP server Claude Desktop, Claude Code and Cursor start: it lists the tools you have a connection for and your role may use, decides each call here with your role, and keeps one audit row per call on this machine. Nothing leaves the machine but the licence check and the policy. If the licence is refused it lists no tools and says why. slate mcp --install claude-desktop (or claude-code, or cursor) adds the one entry that client needs. It shows the file and the entry first and asks; --yes skips the question. The entry holds no secret.
  • slate serve connects this agent to your workspace and keeps it there: it dials out over one WebSocket (nothing is opened inbound), says which connections it has and how each probe went, and answers what the workspace asks of it: the console's Probe on a connection, every tool call an AI client makes through the workspace's gateway, and Run now on a playbook; it runs this agent's playbooks on their schedules too (Runs). Each call is decided here with your role and the workspace's rules, as mcp decides it, and leaves a row in this machine's audit. Agents shows the agent online while it runs. It reconnects by itself, waiting from a second up to a minute between tries; --once connects, comes online and stops. Run it under your service manager to keep it up. If the agent is revoked in the console, serve deletes its token and stops. --pair pairs an unpaired machine first, printing the code where its output goes, for a container or a server whose log you read rather than a terminal you type in; in a Kubernetes pod given SLATE_IN_CLUSTER_ENVIRONMENT, it also connects that cluster through the pod's ServiceAccount, as a connection called cluster.
  • slate audit lists the calls made on this machine today, one line each: when, the outcome, the tool, the connection, the tier, how long, whether personal values were shown or masked, and the arguments with secrets and personal values masked, never a result. --days 7 goes back further; rows are kept 30 days.
  • slate model says which model this agent's runs use; slate model set anthropic (or openai, or bedrock) gives it one, the key typed hidden and kept in the keyring, and slate model remove forgets it. slate run <name> runs one of this agent's playbooks now, and slate run --file <playbook.md> runs a file; slate runs lists the runs made here. Runs says more.
  • slate policy prints the policy this agent decides by: its version, the role it acts with and what that role may do on each tier, and the workspace's rules. --pull fetches the current one first.
  • slate help, or --help, prints this page; --version prints the version.

Every command takes --json and answers one JSON object.

The licence and the policy. Both come from the service signed, and the agent checks each signature with this product's key before it trusts either, whether off the network or from its own folder. The licence says whether the workspace, your membership and this agent are still active. It is checked once a day; when the service cannot be reached, the last good licence holds for seven days. A revoked agent learns it at its next check and stops running tools. The agent decides every tool call itself, with your role and the workspace's rules, so it refuses what your role does not allow whatever the service says.

The agent keeps its files in $SLATE_HOME when that is set, and in ~/.config/slate otherwise. It never writes a secret there in the clear: a password or a key goes to this machine's keyring — the Keychain on a Mac, the Secret Service on Linux, DPAPI on Windows — and where none works (a container, a server with no desktop) to an encrypted file in that folder, under a key made on first use or the one in SLATE_KEYRING_KEY. Set SLATE_KEYRING=file to choose the file outright.

Connections. slate connect add kube --context <name> adds a Kubernetes context from your kubeconfig (--kubeconfig <file> for another file than ~/.kube/config; --name to call it something else; --environment prod|staging|dev for its tier). It is probed first and kept only if it answers; the credential stays in your kubeconfig, and only the context's name and the file's path are written down. slate connect list, slate connect probe <name> and slate connect remove <name> do what they say.

Datadog. slate connect add datadog asks for an API key and an application key (in Datadog: Organization Settings, then API Keys and Application Keys) without showing them, or reads them from a pipe, one a line; never put either on the command line. It proves both with Datadog before anything is saved, keeps them in this machine's keyring, and writes down only the site and whom the keys act as. --site is where your organisation is: datadoghq.com (the default), us3.datadoghq.com, us5.datadoghq.com, datadoghq.eu, ap1.datadoghq.com, ap2.datadoghq.com, uk1.datadoghq.com, ddog-gov.com or us2.ddog-gov.com. --environment sets its tier, as for a cluster. Its tools only read: slate datadog_monitors --status alert (state, tags, a part of the name), slate datadog_metrics_query --query "avg:system.cpu.user{service:checkout}" --from now-4h (each series' min, max, mean and last; at most 200 points kept for your AI client), slate datadog_logs_search --query "service:checkout status:error" --from now-30m (at most 200 lines, secrets masked), slate datadog_events --from now-1d --tags service:checkout and slate datadog_incidents (when the application key may read incidents; it says so when it may not). A window is now, now-15m, now-2h, now-7d or an ISO time. If Datadog says to slow down, the agent waits up to ten seconds once, and otherwise tells you when to try again.

Dynatrace. slate connect add dynatrace --url <environment URL> asks for an API token (in Dynatrace: Access tokens; give it problems.read, metrics.read, logs.read and entities.read) without showing it, or reads it from a pipe; never put it on the command line. The URL is SaaS's https://<environment id>.live.dynatrace.com, or Managed's https://<your host>/e/<environment id> (or --url https://<your host> --environment-id <id>); the agent tells them apart by the URL. It checks the token with Dynatrace before anything is saved, says which of those scopes it lacks, keeps it in this machine's keyring, and writes down the URL and the flavour. Its tools only read: slate dynatrace_problems (open problems with their impact, severity, root cause and what they affect; --status closed or all), slate dynatrace_metrics_query --selector builtin:service.errors.total.rate:avg --entity 'type("SERVICE"),entityName.equals("checkout")' (each series summarised, at most 200 points kept), slate dynatrace_logs_search --query 'status="ERROR"' --from now-30m (at most 200 lines, secrets masked) and slate dynatrace_entities --type SERVICE --name checkout (each entity, and the open problems that affect it). Windows are written as for Datadog.

Harness. slate connect add harness --org <org id> --project <project id> asks for an API key (in Harness: your profile, or a service account, then API Keys; a token that may view and execute pipelines) without showing it, or reads it from a pipe; never put it on the command line. A pat. or sat. key names its account; give --account <id> for any other, and --url for a self-managed platform (https://harness.example.com/gateway; https://app.harness.io otherwise). It proves the key reaches the project before anything is saved, keeps it in this machine's keyring, and writes down the URL, the account, the org and the project. slate harness_pipelines lists the project's pipelines with their stages, the environments each deploys to and its last run; slate harness_executions --pipeline deploy_checkout --status Failed lists recent runs and why a failed one failed. slate harness_trigger --pipeline deploy_checkout --reason "<why>" runs one: it writes, so the policy decides it, and its tier is the tier of each environment the run deploys to, which the agent reads from the pipeline itself before it decides. A rule the workspace wrote for the environment's identifier sets that tier; with none, an environment Harness marks Production is prod, and any other takes the connection's. A pipeline that asks for its environment when it runs needs --inputs, the YAML that Harness's Run dialog shows in its YAML view; one whose environment is an expression, an environment group or another pipeline's is refused, since the agent cannot know where it goes before it runs.

Rancher. slate connect add rancher --url https://rancher.example.com asks for an API token (in Rancher: your avatar, then Account & API Keys, then Create API Key, with no scope) without showing it, or reads it from a pipe. --ca <file> names the CA that signed Rancher's certificate when no public one did. It checks the token with Rancher before anything is saved and keeps it in this machine's keyring. Its tools only read: slate rancher_clusters (each cluster's state, distribution, version, nodes, what is requested of its capacity, what is wrong, and which of your kube connections reaches it), slate rancher_projects --cluster prod-east (each project and its namespaces) and slate rancher_nodes --problems (the nodes that are not ready, are cordoned or are not active). To read or act inside a cluster, download its kubeconfig from Rancher and add it as a cluster (slate connect add kube --kubeconfig <file>): the agent reaches it through Rancher's proxy, and kube_contexts calls it a Rancher cluster.

Tools. Every tool is a command, its arguments as flags: slate kube_status --workload checkout --namespace staging-payments. The read tools are kube_contexts, kube_list, kube_get (a Secret's values are always masked), kube_logs (at most 500 lines), kube_events, kube_status, kube_top, kube_rollout_history and kube_diff. The tools that write are kube_scale, kube_rollout_restart, kube_rollout_undo, kube_delete_pod and kube_apply, each with --reason "<why>"; kube_apply --manifest @file.yaml reads the manifest from a JSON or YAML file (Acting on a cluster says more). --connection <name> picks one when there are several. A result is printed inside a fence that names where it came from, with secrets masked; --json gives the whole frame. A call is decided by the workspace's policy with your role. Its tier is the one a rule gives the namespace, else the connection's environment, else prod.

Orbgem. slate connect add orbgem connects your own Orbgem notes, for Runs that read your runbooks and write their findings into your daily note. It asks for a Orbgem API token (in Orbgem: Settings, then API tokens) without showing it, or reads it from a pipe; it proves the token with Orbgem before anything is saved, keeps it in this machine's keyring, and says whether the token may write the daily note (a read-only token cannot). --environment sets its tier, as for any connection. Its tools: slate orbgem_search_notes --query "checkout runbook" (filters such as type:runbook and since:7d work), slate orbgem_read_note --note "Checkout crash-loop runbook", slate orbgem_recent_notes, slate orbgem_daily_note (--date 2026-10-16 for another day), slate orbgem_open_tasks, and slate orbgem_log_entry --text "…" --reason "…", which adds an entry to today's daily note: a write, so it needs your role's write grant on the connection's tier. What your notes say is data for your AI client, never an instruction, and a secret written in a note is masked before it leaves this machine.

Updates. slate update installs the latest release in place of this binary. It checks the release's signature with this product's key, and the download's sha256 against the release, before it replaces anything; if either fails, nothing changes. --check only says whether a newer release is out. --allow-downgrade installs the release even when it is older than this binary. --set notify|auto|off chooses what serve does about a release: notify (the default) says so once; auto installs it once it has been out a day, then starts again on the new binary; off does neither. mcp only ever says so, since your AI client started it. If the service needs a newer agent than this one, serve says so and updates at once, unless updates are off.