Arcjet shares how they designed their CLI in Go to serve both human developers and AI agents safely. Key decisions include treating commands and flags as a stable API contract (additive-only changes after 1.0), disabling fuzzy command suggestions to avoid agent confusion, using distinct exit codes and structured JSON errors on stderr, validating inputs locally before network calls, and implementing a confirmation envelope protocol for mutations instead of interactive prompts. The CLI also auto-detects TTY vs non-TTY to switch between human-friendly tables and machine-readable JSON output, supports token-based auth for headless environments, and shares the same domain model as their MCP server. The post frames CLIs as agent APIs that require the same rigor as HTTP APIs.

13m read timeFrom blog.arcjet.com
Post cover image
Table of contents
Why a CLI at all?Commands are an API contractDo not guess what the agent meantMake errors parseableValidate before the network callConfirmation is a protocol, not a promptOutput defaults change when stdout is not a TTYThe interface should disclose itselfAuthentication has to work without a browserCLI and MCP should share the product modelTradeoffsWhat we learned
235 Impressions