Skip to main content
AXON ships two CLIs that sit on opposite sides of the runtime / control-plane split. They do different jobs and are safe to install side by side.
The bin names are deliberately distinct (axon vs axon-op) so the two packages can be globally installed without colliding. The distinction also reflects trust: axon hands a worker agent a runtime credential; axon-op is an operator surface and should never be handed to an autonomous worker agent.

Step 1: Runtime bootstrap with @axon402/init

@axon402/init is the canonical first-run runtime bootstrap helper. One command creates your first wallet, mints a wallet-scoped runtime key for that wallet, and wires Claude Code to AXON’s hosted runtime MCP endpoint.
That’s the whole thing. No global install required, no .env, no config file. The installer walks you through one prompt and writes the result to ~/.axon/config.json (chmod 0600) plus a merged entry in ~/.claude.json.
@axon402/init auto-configures Claude Code only. If you use Cursor, VSCode, OpenClaw, or direct REST instead, still run it first to mint the wallet and runtime key, then reuse the generated wallet_id and api_key from ~/.axon/config.json in the manual setup flows under IDE Setup, OpenClaw Plugin, or REST API Integration.
@axon402/init is a one-shot runtime bootstrap, not an ongoing CLI or an operator credential. It creates exactly one wallet and exactly one wallet-scoped runtime key. Re-running it for the same email returns 409 CONFLICT by design. For every later operation — new wallets, new keys, deposits, allocations — use the dashboard or @axon402/cli (axon-op). The runtime key this step issues is intended for an agent to use the prepared wallet through MCP; it is not an operator/admin credential and does not give the agent control over the organization.

What the installer does

  1. Generates a fresh wallet locally. BIP-39 mnemonic, BIP-44 derivation. Two addresses: a vault (HD index 0, the deposit target) and an agent (HD index 1, the spend source). The mnemonic never leaves your machine.
  2. Bootstraps the org + agent + mandate. POST /v1/cli/init sends your email and the two derived addresses. The server creates a Supabase auth user (and emails you a confirmation link), an organization, both wallets, and a starter spending mandate (10 USDC/day, 0.50/tx, 300/mo, hard-stop enforcement).
  3. Mints a wallet-scoped starter API key. Bound to the agent wallet (not the vault — the vault has no mandate by design). Returned to the CLI exactly once and persisted to ~/.axon/config.json.
  4. Wires Claude Code’s MCP config. Merges an HTTP entry for https://api.axon402.com/v1/mcp (or your --endpoint override) into ~/.claude.json, backing the existing file up to ~/.claude.json.bak-<unix-timestamp> first.
  5. Prints a deposit QR code. Scan with Coinbase Wallet, Rainbow, or any Base-compatible wallet to deposit USDC to the vault on Base mainnet. This is an external on-chain transfer — it works the same in both signing modes.

Files written

Optional global install

If you want the axon binary on your PATH (rarely necessary — npx is the supported entry point):

Step 2: The operator CLI

@axon402/cli is the control-plane operator CLI — the terminal companion to the dashboard. Everything that comes after the first wallet — additional wallets, key rotation, deposits, vault allocations, org context inspection — is its job. It is not a runtime surface and should not be handed to an autonomous worker agent.
@axon402/cli is the V1 operator CLI. It uses org-wide operator keys and is separate from the runtime key that @axon402/init writes for worker agents.

What it’s for

  • Auth against the hosted Decision API with an organization-wide operator key (axon_sk_*) created from the dashboard or via POST /v1/api-keys.
  • Manage wallets: list, show deposit addresses + QR, allocate from vault to pocket. Create new wallets in the dashboard for V1.
  • Rotate API keys: create org-wide or wallet-scoped keys; list; mark compromised keys inactive.
  • Inspect org context: dump the org id, signing mode, and scopes resolved from whatever key is logged in.
  • Operate the marketplace surface: search providers.

Current command surface

Authentication model

@axon402/cli uses organization-wide operator API keys as its primary credential. These are long-lived axon_sk_* tokens created either:
  • From the dashboard at /settings/api-keys, or
  • Via POST /v1/api-keys (see API Keys reference)
Both paths write to the api_keys table using the same HMAC-SHA256 hashing the Decision API uses on the read side, and the plaintext is returned to the caller exactly once.
The wallet-scoped starter key that @axon402/init writes to ~/.axon/config.json is a runtime key. It is intended for an agent to call governed_fetch and the rest of the runtime MCP surface against the prepared wallet — it is not an operator credential. For daily control-plane ops, create an org-wide operator key from the dashboard or POST /v1/api-keys and hand it to axon-op auth login. One key = one surface.
If you do log in with a runtime key by mistake, axon-op auth login and axon-op auth whoami will show surface: runtime. Read-oriented commands remain available, but write paths such as keys create, wallets allocate, and offers create refuse with TOOL_NOT_AVAILABLE_IN_RUNTIME_SURFACE until you re-login with an org-wide key.

Installation sanity check

For IDE-native MCP-driven operator automation (a separate, advanced use case), the operator / manage MCP surface is documented separately in Integrations → IDE Setup. Day-to-day operator work is still best done from axon-op or the dashboard.
axon-op auth whoami calls GET /v1/me on the hosted Decision API. A successful response tells you the org id, the org’s signing mode (full or browser), and the scopes available to the key.

Requirements (both CLIs)

  • Node.js: @axon402/init requires >=18; @axon402/cli requires >=20
  • OS: macOS, Linux, or WSL on Windows. Native Windows is untested but should work because neither CLI has native dependencies.
  • Network: outbound HTTPS to https://api.axon402.com and https://registry.npmjs.org

Next steps

  • See the CLI reference for @axon402/init flags, environment variables, exit codes, and troubleshooting.
  • See the POST /v1/cli/init endpoint reference for the API that @axon402/init calls.
  • See GET /v1/me for the auth introspection endpoint @axon402/cli uses at login.
  • Sign in to the hosted dashboard (you’ll receive a confirmation email) to view ledger entries, approve spend requests, and edit the mandate.