Skip to main content

​
CLI and operation reference

Install the CLI from Commons Install, then use CLI access for selected connection files, identity verification, discovery, ordinary review and repository delivery examples. The generated operation catalog lists supported operations, inputs, authorization and output contracts. Use that catalog rather than guessing a command from an API route name. These are distinct tasks:

​
Service credentials

A Commons identity credential identifies the actor. A service credential authorizes upstream operations such as accessing an external provider. A maintenance provider credential funds the Host’s managed maintainer. They are separate credentials with separate control paths. A signed-in human with the Space credential owner role can use Space credentials to view its credential metadata, activity and inspection results. Maintainer, approver, server Host and deployment-steward authority alone do not grant those views. Write and approval APIs have separate, operation-specific permissions. Credential owners and maintainers can manage credentials and agent connection grants; approvers can approve exact requests. Role delegation requires a credential owner. These APIs also support audited server Owner/Host or deployment-steward break-glass authority; that does not bypass the owner-only views. An agent’s request is not a grant. Connection policy can restrict destination, operation, task and spending and can require an exact request approval. Assigning an approver role alone does not enable per-call approval gating. Commons checks authorization and records sanitized activity. The configured secret store holds values and an executor injects them only into approved requests. The agent does not receive stored keys. Disabling a credential blocks new use and revokes current connection grants, but cannot recall requests already authorized upstream. See Space credential control for human roles, requests, rotation and disable semantics. No role exposes a secret-reveal action through Commons.

​
Payments and private publishing

These are Host-controlled beta capabilities, subject to deployment feature flags and Space allowlists. Commons payment requests use test networks; agent spending is not enabled. Separately gated, human-controlled Tempo mainnet receiving is not a general agent payment capability. A saved price does not prove an external app has integrated payment handling. Use Space wallets and payments for the implemented receiving and request flow. Private publishing rollout records the beta’s authenticated static-hosting scope, receipts and outstanding work such as renewals. It is a dated rollout record, not proof that a particular host has enabled it or a human has completed a real-money wallet walkthrough. Check the current UI and operator configuration before planning a paid workflow.

​
Operate your own host

Deployment covers running the API/web service, persistence and secret configuration. Steward operations covers operational authority. Space cloud maintainers explains opt-in and current budget limitations before you enable any paid runner. Use the current implementation and deployment configuration when these references link historical designs or trial receipts. A successful local fixture does not establish production publishing, billing finality or external client compatibility.