How it works
The CLI channel only activates when Curia runs directly on the host with a terminal attached. The standard Docker deployment (pnpm run setup → docker compose up) does not include the CLI. To use the CLI, stop the container and run Curia on the host instead:
pnpm local starts all services and presents a text prompt. Type a message and press Enter to interact with Curia directly. Responses appear in the same terminal.
The CLI adapter publishes inbound.message events on the bus, just like every other channel. Your messages pass through the same dispatch pipeline — trust scoring, rate limiting, injection scanning — before reaching the Coordinator. The only difference is the channel trust level: CLI is always high.
Trust level
| Property | Value |
|---|---|
| Trust level | High |
| Reasoning | Local access only — no network exposure, no identity spoofing |
| Sender identity | Always treated as the CEO (contactId: "primary-user") |
When to use the CLI
- Development and testing — the fastest way to interact with Curia during development
- Administrative tasks — checking autonomy score, managing contacts, processing held messages
- Troubleshooting — direct access with full trust, useful when debugging channel-specific issues
- Direct host runs — when developing against
pnpm localrather than the Docker stack, the CLI is available immediately, before any external channels are configured
Limitations
- Single session — one conversation at a time, tied to a fixed conversation ID
- No persistence across restarts — the readline session ends when Curia stops (but working memory persists in Postgres, so context from previous CLI conversations is retained)
- Local only — requires terminal access to the machine running Curia
How channels work
Channel routing, trust levels, and how messages flow through the dispatch layer.
Deployment
Get Curia running so you can use the CLI.