strix-cli 0.2.0

Command-line interface for Strix — run governed actions through the kernel and verify the signed evidence

strix-cli

Command-line interface for Strix governance evidence verification.

Wraps the strix-verify Python package into ergonomic commands for operators, SREs, and CI pipelines. Every evidence record produced by the Strix platform can be independently verified using only standard cryptographic primitives (Ed25519 + SHA-256) — no Strix SDK or account required.

Install

# From the monorepo (editable)
cd python/strix-cli
pip install -e .

# Verifies you have the CLI available
strix version

Minimum Python 3.10.

Quick Start

# Verify an evidence record end-to-end
strix verify 12345

# Same, but emit JSON for scripting
strix verify --json 12345 | jq '.signatureValid'

# Check endpoint reachability
strix health

# Walk through the verification steps one at a time
strix simulate 12345

# Confirm your local environment is set up correctly
strix doctor

Commands

Connected execution (governed run)

strix run executes a governed action through the hosted Strix kernel in connected mode (a tenant sk_ API key), end-to-end:

evaluate → (operator approval for HIGH+) → execute → close the proof loop

On success it emits a verifiable proof reference you can check with the same CLI:

export STRIX_API_KEY=sk_live_...        # tenant key from the Console
export KERNEL_URL=https://www.strixgov.com

strix run notification.send --env production --ack "sending the release note"
# → APPROVED — token: ...
#   PROOF — evidenceId: <id>   verify: npx @strixgov/verifier <id>

strix verify <id>                       # verify the record this run produced

A machine tenant key never self-approves. HIGH-risk actions return the Console approval URL and fail closed (exit 25) unless a human approves; pass --wait [seconds] to block and poll until approved, then execute:

strix run member.role.update --env production --ack "promote alice to admin" --wait 300

Exit codes are aligned with the solo CLI: 0 ok · 20 not-configured · 21 unreachable · 22 denied · 24 timeout · 25 pending-approval · 26 approval-timeout · 40 bad input.

Verification

Command	What it does
strix verify <id>	Fetch + verify a record by evidence ID
strix verify-file <path>	Verify a record from a JSON file
strix fetch-proof <id>	Fetch a raw record without verifying
strix simulate <id>	Dry-run verification step by step

Layer 2 deployment-context checks (SE-14) are opt-in:

strix verify 12345 --expect-env production --expect-tenant acme-corp

Historical JWKs for key rotation can come from a file or the STRIX_SIGNING_JWKS_EXTRA env var:

strix verify 12345 --extra-keys ./historical-keys.json

Diagnostics

Command	What it does
strix health	Ping proof API + JWKS endpoint
strix jwks	Print the live JWKS
strix jwks --kid strix-prod-2026-04	Filter to a single key
strix doctor	Full environment check (Python, deps, network, env flags)
strix version	Print CLI + verifier versions

Capability Registry

Command	What it does
strix capability list	List every capability in the registry
strix capability list --bucket identity-access	Filter by bucket
strix capability show <id>	Show a single manifest
strix capability scaffold <bucket>.<name>	Create a new capability skeleton
strix capability validate <path>	Validate a manifest without registering
strix capability register <path>	Validate + register

The CLI auto-discovers capabilities/ by walking up from cwd, or you can pass --registry explicitly.

Output Modes

All commands support two output modes:

• Human (default): Rich-formatted tables with color. Good for terminals.
• JSON (--json): Stable, machine-readable JSON. Good for CI, jq, scripts.

Errors and progress logs go to stderr; primary output goes to stdout. This means strix verify <id> > result.json captures only the structured result.

Exit Codes

The CLI uses distinct exit codes so CI pipelines can tell transient failures apart from verification failures:

Code	Meaning
0	Command succeeded / record VERIFIED
1	Verification failed (tamper, unsigned, missing key, compliance violation)
2	Environment or network error (transient — safe to retry)

Example: CI Verification

#!/usr/bin/env bash
# Block a deploy if any evidence from the last 100 records fails verification.
set -euo pipefail

for id in $(strix fetch-recent-ids --limit 100); do
  if ! strix verify --quiet "$id"; then
    echo "Evidence $id failed verification" >&2
    exit 1
  fi
done

Example: Cross-Environment Replay Detection (SE-14)

Strix stores the signing environment and tenantId on the record, never read from process.env at verification time. This lets you catch cross-environment replays without special infrastructure:

# In your production verification job:
strix verify 12345 --expect-env production --expect-tenant acme-corp
# → environmentMatch: false  ⇒  record was signed in staging, not production

Architecture Notes

This CLI is a thin presentation layer over strix-verify. It:

• Does not store, cache, or persist evidence records.
• Does not require Strix credentials. Public JWKS + public proof API only.
• Does not assert compliance flags — they are always derived from verification outcomes (CI-5).
• Reads environment and tenantId from the stored record fields only (SE-14).

If you need to embed verification into a larger Python application, import the strix_verify package directly.

License

MIT