██╗  ██╗ ██████╗ ███╗   ██╗ ██████╗██╗  ██╗ ██████╗
██║  ██║██╔═══██╗████╗  ██║██╔════╝██║  ██║██╔═══██╗
███████║██║   ██║██╔██╗ ██║██║     ███████║██║   ██║
██╔══██║██║   ██║██║╚██╗██║██║     ██╔══██║██║   ██║
██║  ██║╚██████╔╝██║ ╚████║╚██████╗██║  ██║╚██████╔╝
╚═╝  ╚═╝ ╚═════╝ ╚═╝  ╚═══╝ ╚═════╝╚═╝  ╚═╝ ╚═════╝

honcho-cli

A terminal for Honcho — memory that reasons.

Install

As a standalone tool (recommended):

uv tool install honcho-cli

Quick Start

honcho init        # confirm/set apiKey + Honcho URL in ~/.honcho/config.json
honcho doctor      # verify your config + connectivity
honcho             # show banner + command list

honcho init reads apiKey and environmentUrl from the top-level of ~/.honcho/config.json (the same file other Honcho tools — plugins, host integrations — share). If both are present, it confirms them with you; if either is missing (or you decline), it prompts for the missing value(s) and writes them back. Host-specific entries under hosts are left untouched.

Per-command scoping (workspace / peer / session) is handled via -w / -p / -s flags or HONCHO_* env vars — not persisted as CLI defaults.

Commands

Onboarding

Workspaces

Peers

Sessions

Messages

Conclusions (observations)

Config

Agent Usage

All commands output JSON when stdout isn't a TTY, or when --json is forced. Collection commands emit JSON arrays, and single-resource commands emit JSON objects:

honcho peer list --json
honcho workspace inspect --json | jq '.peers'
honcho doctor --json              # machine-parseable health checklist

Errors are structured:

{
  "error": {
    "code": "PEER_NOT_FOUND",
    "message": "Peer 'abc' not found in workspace 'my-ws'",
    "details": {"workspace_id": "my-ws", "peer_id": "abc"}
  }
}

Non-interactive onboarding:

# Pre-seed via flags / env vars; init still prompts for anything missing
HONCHO_API_KEY=hch-v3-xxx honcho init --base-url https://api.honcho.dev

Agent skill

honcho-cli ships with a skill that teaches agents the right commands and conventions for inspecting and debugging a Honcho deployment. Install it anywhere skills are accepted (Claude Code, other skill-aware agents):

npx skills add plastic-labs/honcho

The picker lists every skill for Honcho — select honcho-cli .

Environment Variables

All HONCHO_* env vars work at runtime — no config file required.

Precedence (highest first): flag → env var → config file → default.

# Per-command flags
honcho peer card -w prod -p user

# Or export once per shell
export HONCHO_WORKSPACE_ID=prod
export HONCHO_PEER_ID=user
honcho peer card

# One-off against a different server
HONCHO_BASE_URL=http://localhost:8000 honcho workspace list

# CI/CD — env vars only, no config file needed
export HONCHO_API_KEY=hch-v3-xxx
export HONCHO_BASE_URL=https://api.honcho.dev
honcho workspace list

Configuration

The CLI shares ~/.honcho/config.json with sibling Honcho tools. It owns two top-level keys: apiKey and environmentUrl (the full Honcho API URL, e.g. https://api.honcho.dev or http://localhost:8000). Everything else at the top level — hosts, sessions, saveMessages, sessionStrategy, etc. — is left untouched.

{
  "apiKey": "hch-v3-...",
  "environmentUrl": "https://api.honcho.dev",
  "hosts": { "claude_code": { "...": "..." } }
}

workspace_id / peer_id / session_id are per-command only — never persisted to the config file.

Development

Install from source in editable mode so changes are picked up live:

git clone https://github.com/plastic-labs/honcho
cd honcho
uv tool install --force --editable --from ./honcho-cli honcho-cli

Re-run any time — changes to honcho-cli/src/ are reflected immediately without reinstalling.

License

MIT