agent-infra-cli 0.2.1

# Agent Infra CLI

`infra` is a command-line client built on `agent-infra-sdk`. Infra services use
the Agent Infra Gateway. File and command operations go through Environment
Computer and Space APIs.

## Install

```bash
cargo install agent-infra-cli
```

The default Gateway is `http://127.0.0.1:5200`. Persist a remote Gateway once:

```bash
infra config gateway set https://infra.example.com
infra config gateway get
```

Resolution order is `--gateway` > `SKY_GATEWAY_URL` > saved config > local
default. Override the config path with `--config` or `AGENT_INFRA_CONFIG`.
The default path is:

- macOS: `~/Library/Application Support/agent-infra/config.json`
- Linux: `${XDG_CONFIG_HOME:-~/.config}/agent-infra/config.json`
- Windows: `%APPDATA%\agent-infra\config.json`

Environment configuration remains supported:

```bash
export SKY_GATEWAY_URL=https://infra.example.com
export SKY_GATEWAY_TOKEN=...
```

Do not put a long-lived token directly on the command line in shared shell
environments; process arguments and shell history may be visible to others.
The config file stores only the Gateway URL, never credentials.

## Sky credentials

Credential resolution order is `--token` > `SKY_GATEWAY_TOKEN` > a directly
readable local `~/.sky/credentials` token. Inspect discovery without printing
secrets:

```bash
infra auth status
```

Modern `sky login` credentials use an `ENCv1` encrypted store. Infra detects
that login state but deliberately does not decrypt another CLI's credential
file. In that case, issue a scoped Sky user API token and expose it as
`SKY_GATEWAY_TOKEN`. `infra auth status` reports this as
`sky_login_encrypted` and provides the same guidance.

## Examples

```bash
# Health and discovery
infra gateway ready
infra gateway wait-ready --deadline 60
infra gateway discovery --output json

# Agent Registry
infra agent list --status active --limit 20
infra agent get agt_01K...
infra agent create --file create-agent.json

# Runtime Identity lifecycle
infra runtime create --name code-dev
infra runtime get rti_01K...
infra runtime rename rti_01K... code-staging --expected-revision 1
infra runtime activate rti_01K... --file activate-runtime.json
infra runtime permissions rti_01K... --file runtime-permissions.json
infra runtime bootstrap-credential --file runtime-bootstrap.json
infra runtime revoke rti_01K... --file revoke-runtime.json

# Agents are configurations bound to Runtime IDs; reverse lookup stays here
infra agent list --related-runtime-id rti_01K...

# Durable context; append accepts an array of ConversationRecord objects
infra context recent conversation-1 --limit 50 --role user,assistant
infra context append --file messages.json

# Environment computers and spaces
infra computer list
infra space list

# OpenAI-compatible Model Infra JSON APIs; '-' means stdin
infra model models
infra model chat --file request.json
printf '%s' '{"model":"default","input":"hello"}' | infra model responses
```

Complex write requests are supplied as JSON files or standard input so the CLI
stays aligned with the SDK's contract types as those contracts evolve. JSON
field names use the contracts' `camelCase` wire format.

`infra runtime create` prints the complete `CreateRuntimeIdentityResponse`.
On the first successful create this includes the one-time `bootstrapToken`;
treat stdout as secret-bearing output and do not write it to shared logs.
After permissions are installed and the identity is active,
`runtime bootstrap-credential` exchanges that proof through the public Gateway
bootstrap endpoint. Its JSON output also contains a secret workload token.

The common create path takes a mutable name directly and defaults `kind` to
`code`. The service derives a deterministic idempotency key from the normalized
creation name, so callers normally do not pass one:

```bash
infra runtime create --name code-dev
infra runtime create --name tool-dev --kind tool
```

`runtime_id` remains stable when the name changes:

```bash
infra runtime rename rti_01K... code-staging --expected-revision 1
```

Use `--idempotency-key` only to control an exceptional retry scope. The
advanced `--file` form remains available for a complete request document:

```json
{
  "name": "code-dev",
  "kind": "code",
  "metadata": {}
}
```

Lifecycle commands (`activate`, `suspend`, `resume`, and `revoke`) accept a
`TransitionIdentityRequest` document:

```json
{
  "expectedRevision": 1,
  "idempotencyKey": "activate-runtime-01",
  "reason": "runtime provisioning completed"
}
```