Command Line Reference

The openseal binary carries every entry point: the terminal client, the daemon, the deterministic runbook tools, and the offline Skill and bundle utilities. Running it with no subcommand opens the terminal client.

Commands

An unrecognized subcommand prints usage to standard error and exits 1.

The subcommand is workflow, the API resource is runbooks. The deterministic HCL layer is named both ways depending on where it is being addressed. Both refer to the same thing.

openseal daemon

Starts the durable kernel and the versioned API. See Configuration for the files it reads.

A missing --config file is created with defaults. A missing --context file is treated as an unconfigured local credential source, not an error.

openseal tui

Opens the terminal client. This is what runs when the binary is invoked with no subcommand.

openseal
openseal tui --endpoint http://127.0.0.1:8080 --scope local:default

OPENSEAL_API_URL sets the default endpoint, and --endpoint overrides it. An endpoint with a path component is treated as an explicit canonical API root rather than an origin, which is how the client operates against a kernel mounted under a host's own route prefix. An endpoint with no path has /api/v1 appended.

The Terminal Interface

The terminal client is a thin client over the API. It owns no authoritative state, and closing it leaves the daemon and all durable work running. It renders only the destinations the connected server advertises in its capability document, so a daemon without a given capability produces a client without that destination.

Layout

The workspace is a single full-terminal view. A row of primary destination labels sits across the top, with a second More row beneath it holding the remainder, and a hint line showing the arrow-key and help bindings. Below the navigation, the main panel renders the selected destination — a list of Runs, a channel transcript, a bundle inspection, and so on. A composer occupies the lower portion of the view on destinations that accept input, and Tab moves focus between the composer and the panel above it.

Home presents the next useful action rather than a dashboard, and states the shape of the workflow directly: describe, review the exact proposal, create, activate, observe. Creation and activation stay separate throughout — the client never starts unreviewed work.

Destinations

Seven destinations are primary. The remainder appear under the More row. Each carries a single-key shortcut.

Home is always present. Every other destination appears only when its capability is advertised. Marketplace appears when any one of the ClawHub, Skill action, Skill binding, or source policy capabilities is available.

Integrations does not appear against the bundled daemon. That destination is gated on the conversation gateway capability, which the standalone daemon never emits. It is reachable only against an embedding host that composes its own capability document.

Keys

Headers and Downloads

The client refuses to send Content-Type or Idempotency-Key through --header, rejecting them at flag-parse time with a message naming them as kernel-protocol headers. Header names and values containing whitespace, colons, or line breaks are also rejected, which prevents header injection through the flag.

Downloaded artifacts are verified against their recorded digest before being moved into the download directory.

openseal run

openseal run workflow.hcl

Loads the HCL file, converts it into an executor pipeline, and executes it with a thirty-minute timeout, starting from the first node in the file. On completion it logs the runbook name, node count, edge count, source file, status, and duration, then prints each node's output as indented JSON.

This is the deterministic layer, not the durable kernel. A runbook executed this way creates no Run, produces no activity events, and passes through no approval. See Concepts.

openseal validate

openseal validate workflow.hcl --json

Checks node identifiers for emptiness and duplication, node types against known metadata and the executor registry, edges for missing or unknown endpoints, node configuration against each type's input schema, and the graph for cycles and orphaned nodes.

Self-loops and unknown configuration fields are warnings; everything else is an error. --json prints the machine-readable result. A parse failure or any error-level issue exits 1.

Run it from the repository root. Node metadata is read from embedded_nodes/, resolved against the process's working directory. From the repository root all 28 node types are known and each node's configuration is checked against its schema. Run from anywhere else, the metadata is unavailable, configuration is not checked at all, and the trigger and tool types are reported as unknown node types — so the result only means what it says when the command is run from the root.

openseal workflow create

Writes a two-node scaffold: a webhook trigger node with a path derived from the name, an http node pointing at https://example.com, and an edge between them.

The scaffold runs as written. Its first node is a webhook trigger, which has no registered executor but is handled before the executor lookup — it passes its data payload to the http node downstream and execution continues. See API for which node types execute and which stop a run.

openseal skill

openseal skill manifest <skill-id> --output ./outreach.yaml
openseal skill validate ./outreach.yaml

manifest encodes one of the four bundled Skill definitions as a YAML manifest, writing to standard output or to --output with mode 0644. An unknown identifier reports the available list. validate decodes a manifest file and prints valid <id>@<version>.

openseal bundle

openseal bundle validate <path>
openseal bundle inspect <path>
openseal bundle diff <from-path> <to-path>
openseal bundle plan-upgrade <current-path> <target-path>

All four read files directly and print indented JSON without contacting a daemon. validate verifies against an empty trust policy and reports the digest along with any valid signature keys. See Workforces.

Next Steps

• Configure the daemon these commands start in Configuration.
• Reference the routes the client consumes in API.
• Understand what --standalone-operator grants in Security.