Configuration

xops has two configuration surfaces: its own ~/.xops/config.yaml (channels, memory), and goose's provider config (which LLM powers the engine).

xops config

file: ~/.xops/config.yaml

channels:
  telegram:
    enabled: true
    accounts:
      default:
        token: "<bot-token-from-@BotFather>"
        allowFrom:
          - your_telegram_username

memory:
  path: ~/.xops/memory.db

• allowFrom — usernames permitted to talk to your bot. Empty list = anyone. Always set this.
• There is no AI provider section here. The LLM is goose's concern.

Engine (goose) configuration

xops spawns goose run for every action and chat turn. Which model answers is decided by goose:

goose configure

Provider selection per xops run can override goose's default via environment variables:

XOPS_PROVIDER=ollama XOPS_MODEL=qwen25-32k bun scripts/poc-run.ts docker xops-victim

Variable	Meaning	Default
XOPS_PROVIDER	goose provider for engine runs (ollama, anthropic, ...)	goose's configured default
XOPS_MODEL	model name passed to goose	goose's configured default

recommendation: use a native goose provider (ollama, anthropic). The claude-acp bridge provider has known issues driving xops runs — hangs on parallel tool calls and no skill passthrough.

Scoped credentials (Kubernetes)

Action runs against Kubernetes use a namespace-scoped kubeconfig generated by:

bash scripts/provision-poc-rbac.sh <namespace> [context]

The engine sets KUBECONFIG to this file for the run. Tokens expire after 2 hours — re-run the script to refresh.

Skill grants

Each skill declares the commands it may use in its frontmatter:

metadata:
  xops:
    grants: [ps, inspect, logs, stats, events, restart, update]

The guard denies anything outside the grants, and denies CRITICAL-tier commands (rm, delete, prune, ...) even if granted.