Documentation Getting started

Examples

Start with a working CLI example, then explore the agent handoff and app-testing workflows Cella is building.

On this page

Inspect your setup

Available today · CLI inspection

After building the CLI or using the Debian CLI-only bootstrap, inspect its version, build information, and runtime prerequisites. Run these from the repository root.

Inspect the current CLI
./target/debug/cella --version
./target/debug/cella info
./target/debug/cella doctor --wall

Alternative: installed Debian CLI

If you used the bundled CLI on Debian 13 x86-64, Rust and a C compiler were not required. Use its installed command name:

Inspect the bundled CLI
cella --version
cella info
cella setup --plan
cella doctor --wall

The bundled unsigned alpha artifact is SHA-256 checked by ./install.sh. It installs only the user-local CLI, not the runtime. setup --plan remains read-only and reports that release installation is not authorized.

What to expect: version and build-target information, followed by a report of runtime prerequisites. Before runtime setup, missing dependencies and a nonzero doctor exit are expected. These commands inspect your setup; they do not start an agent.

Explore the CLI reference

Continue a password reset task

Planned workflow

You start a password reset feature with Codex. Later, you want Claude to finish the tests without reconstructing the work.

  1. Start the task. Codex edits a private repository copy within a Workstream for the password reset feature.
  2. Save a checkpoint. Retain the files, declared task state, completed checks, and notes about what remains.
  3. Hand off the work. Claude starts a new Run from that checkpoint and finishes the reset-token tests.
  4. Review the result. Inspect the selected patch, checks, policy, and required approvals together before delivery.
CodexBuild the featureCheckpointFiles + task stateClaudeFinish the tests

The checkpoint carries explicit work state and handoff notes. It does not transfer hidden model reasoning.

How Workstreams carry the task

Test an app with scoped access

Planned workflow

The reset flow depends on an app and a database. The agent needs to test the behavior; the database credentials belong to the app.

  1. Run the app separately. A Service Cell runs an approved, sealed app revision with its own authorized secrets.
  2. Grant the test connection. A named Channel allows the Agent Cell to reach the approved app endpoint.
  3. Check the behavior. The agent tests reset-token expiry through that scoped connection, without receiving the app’s reusable credentials.
  4. Approve updates explicitly. Testing new code in a secret-bearing service requires a new sealed revision and the applicable policy and approvals.
The access boundary

A connection to the app does not grant general host networking or permission to read the Service Cell’s secrets.

Agent Cells, Service Cells, and Channels