CLI

The zunder-guard commands, and the zunder-runner commands they are modelled on.

Command	What it does	Who	Today’s model
`zunder-guard init --interactive [--rules zr1_…] [--account 0x…] [--no-key] [--force]`	guided setup on the terminal: keep or edit the rules, the account, the mode (paper by default; mainnet typed in full, then the account again), then the key with hidden input; writes the config and starts the journal	a person	`zunder-runner journal-init`
`zunder-guard init --non-interactive --rules zr1_… --network N [--account 0x…] [--confirm-mainnet 0x…] [--equity-cap USDC] [--key-stdin\|--no-key] [--listen L] [--force]`	the same without prompts; refuses anything missing. A mainnet key is checked and its address recorded, never stored	an installer, cloud-init	new
`zunder-guard run [--network N] [--listen L] [--key-stdin\|--key-file F]`	run until stopped; mainnet needs `ZUNDER_GUARD_MAINNET_CONFIRM` naming the account at every start	a person or a service	`zunder-runner testnet` / `mainnet`
`zunder-guard pair`	a client key for a bot, printed once, with a pairing code	a person	new
`zunder-guard key check --key-stdin`	checks the key on standard input is an API wallet of the configured account; prints the wallet address, never the key	the installer	new
`zunder-guard config get network\|account\|listen\|rules`	prints one configured value	anyone on the machine	new
`zunder-guard health [--listen L\|--url U]`	exit 0 if `/healthz` answers 200	a healthcheck	new
`zunder-guard status`	risk state, positions, last decisions	anyone on the machine	`status.json`
`zunder-guard kill --reason "…"`	pull the kill switch	anyone on the machine	`zunder-runner kill`
`zunder-guard resume --note "…"`	clear a drawdown halt after a review	a person	`zunder-runner journal-resume`
`zunder-guard journal show`	print the journal	anyone on the machine	`zunder-runner journal-show`
`zunder-guard journal repair --note "…"`	cut a torn last record	a person	`zunder-runner journal-repair`
`zunder-guard check-config`	validate the config; no key, no network	anyone	`zunder-runner check-config`
`zunder-guard client add\|list\|revoke`	manage client keys for bots	a person	new
`zunder-guard-mcp` (later also `zunder-guard mcp`)	run the MCP server over stdio	an MCP client	new
`zunder-guard rules export`	print your rules as a `zr1_` code	anyone	new
`zunder-guard --version`	the version	anyone	new

The commands an installer or a container relies on (init, run, pair, key check, config get, health, --version) follow the contract in deploy/guard/README.md. Every flag also has an environment variable (ZUNDER_GUARD_HOME, ZUNDER_GUARD_RULES, ZUNDER_GUARD_NETWORK, ZUNDER_GUARD_ACCOUNT, ZUNDER_GUARD_LISTEN, ZUNDER_GUARD_KEY_FILE, ZUNDER_GUARD_MAINNET_CONFIRM), so a container without a shell can be configured. A refusal exits with status 2 and the reason on standard error.

Commands only a person runs

init, pair, resume, journal repair and client add change what Guard may do. They are never called by Guard itself, by the MCP server, by the monitor page or through the relay. resume also needs Guard stopped, as zunder-runner journal-resume does today.

Example

zunder-guard kill --reason "bot looping on SOL"
zunder-guard status
# state: killed (bot looping on SOL) · positions: none · session: killed

This page as plain Markdown, for people and LLMs: /docs/reference/cli.md