Skip to main content
The palyra CLI is the primary entry point for operators to manage both local and remote Palyra runtimes. It provides a comprehensive command hierarchy for bootstrapping, diagnostics, agent interaction (ACP/MCP), and system administration.

Command Hierarchy and Architecture

The CLI is built using clap for declarative argument parsing and command dispatch. The root command structure is defined in crates/palyra-cli/src/args/mod.rs, which aggregates subcommands from various domain-specific modules.

Core Command Groups

GroupCommandsPurpose
Lifecyclesetup, configure, onboarding, uninstall, updateInstallation, initial configuration, and maintenance.
Diagnosticsdoctor, health, status, logs, systemEnvironment verification and runtime observability.
Protocolsacp, mcp, tuiAgent Control Protocol, Model Context Protocol, and TUI.
Managementprofile, auth, secrets, policy, configIdentity, connection profiles, and security configuration.
Runtimegateway, node, nodes, sandbox, pluginsDaemon control, node management, and isolation policies.
Datamemory, objectives, routines, sessions, backupPersistence, long-term goals, and automation schedules.
Sources: crates/palyra-cli/src/args/mod.rs#138-157, crates/palyra-cli/src/lib.rs#78-91

Command Dispatch Flow

The CLI follows a standard pattern:
  1. Parse: Cli::parse() generates a Cli struct crates/palyra-cli/src/lib.rs#77-77.
  2. Context Initialization: The RootCommandContext is built to resolve profiles, state roots, and logging levels crates/palyra-cli/src/app/mod.rs#151-157.
  3. Dispatch: The run function matches the CliCommand enum to specific handler functions in crates/palyra-cli/src/commands/ crates/palyra-cli/src/commands/mod.rs#1-52.

CLI Parity Matrix

The codebase maintains a CLI Parity Acceptance Matrix to ensure consistency across platforms (Unix/Windows) and feature completeness.

Canonical Command Map

To improve discoverability, several commands serve as preferred aliases for underlying subsystems:

Connection Profiles and Environment Selection

The CLI uses Connection Profiles to manage multiple Palyra environments (e.g., local, staging, prod).

Profile Implementation

Profiles are stored in a profiles.toml file within the CLI state root crates/palyra-cli/src/app/mod.rs#26-26. The CliConnectionProfile struct tracks:

Profile Dispatch Logic

Sources: crates/palyra-cli/src/app/mod.rs#151-161, crates/palyra-cli/src/commands/profile.rs#215-250

Output Formats and Serialization

The CLI supports three primary output formats, controlled by the --output-format global flag crates/palyra-cli/tests/help_snapshots/root-help-unix.txt#78-80:
  1. Text (Default): Human-readable tables and stylized output.
  2. JSON: Single valid JSON object for scripting.
  3. NDJSON: Newline-delimited JSON for streaming data (e.g., logs or run events).
The RootCommandContext provides helper methods prefers_json() and prefers_ndjson() to allow command handlers to branch their rendering logic crates/palyra-cli/src/app/mod.rs#204-210.

Subsystem Details

1. Setup and Onboarding (setup, onboard)

The setup command invokes the operator_wizard crates/palyra-cli/src/commands/mod.rs#29-29. It supports a --flow quickstart mode for non-interactive bootstrapping, which automatically handles API key injection and config generation crates/palyra-cli/tests/wizard_cli.rs#68-91.

2. Diagnostics and Doctor (doctor, health)

The doctor command performs environment checks, including:

3. Agent Bridges (acp, mcp)

4. Memory and Learning (memory)

The memory command family allows operators to manage the daemon’s long-term memory: Sources: crates/palyra-cli/src/commands/memory.rs#1-10, crates/palyra-cli/src/args/memory.rs#1-84

Data Flow: From CLI to Daemon

This diagram illustrates how a CLI command (e.g., palyra gateway status) traverses the application layers. Sources: crates/palyra-cli/src/app/mod.rs#212-225, crates/palyra-cli/src/lib.rs#24-28, crates/palyra-cli/src/commands/status.rs#1-20