Overview
DefenseClaw is two CLIs by design. The Python CLI (defenseclaw) is the operator surface — provisioning, policy, scanners, audit. The Go CLI (defenseclaw-gateway) manages the daemon that actually enforces verdicts, persists audit rows, and speaks WebSocket to OpenClaw. Everything the TUI does shells to one of these two binaries. Everything CI does should also shell to one of these two binaries. There is no third surface.
Rendering diagram…
Which CLI for which job
| Task | CLI | Command |
|---|---|---|
| Initialize a fresh install | defenseclaw | init |
| Start / stop / restart the daemon | defenseclaw-gateway | start, stop, restart |
| Daemon health + subsystem state | defenseclaw-gateway | status |
| Config validation and mutation | defenseclaw | config, settings |
| Scanners (skill, MCP, plugin, code) | both | skill scan, mcp scan, plugin scan, defenseclaw-gateway scan code |
| Admission (block, allow, quarantine) | defenseclaw | skill block, mcp block, etc. |
| Policy (Rego + rule packs) | both | defenseclaw policy list, defenseclaw policy test, defenseclaw-gateway policy reload |
| Audit activity + export | both | defenseclaw audit log-activity, defenseclaw-gateway audit export |
| Wizards / setup flows | defenseclaw | setup ... |
| Provider key operations | defenseclaw | keys list, keys set, keys check |
Rule of thumb: if it's something an operator decides, it's defenseclaw. If it's process management for the daemon, it's defenseclaw-gateway. The Python CLI calls the sidecar over REST; the Go CLI is the daemon.
Global conventions
Both CLIs follow the same conventions so scripts can assume:
- JSON output is command-specific; check the generated options table before scripting it.
--yesis available on selected mutating commands that need confirmation bypass.- Exit code
0on success, specific codes for specific failure classes. See Exit codes. --quietand--verboseare command-specific, not global flags.