---
title: "CLI"
description: "How the executor CLI fits into the system and why it stays thin."
---

The CLI lives in `apps/executor`.

Its job is to be the installed user-facing shell around the local daemon, not the place where product logic is implemented.

## Responsibilities

The CLI is responsible for:

- starting and stopping the local daemon
- checking daemon health and installation state
- submitting executions
- resuming paused interactions
- packaging and distribution concerns for the installed binary

## What it should not own

The CLI should not own:

- source persistence rules
- auth workflows
- tool discovery
- execution state machines
- tool invocation behavior

Those belong in the control plane.

## Why this boundary matters

This split is intentional.

It means the browser UI, CLI, and local MCP entrypoint all talk to the same product core instead of each carrying their own business logic. That keeps behavior consistent across entrypoints and avoids reimplementing source, credential, and execution rules in multiple places.

## How it talks to the rest of the system

At a high level, the CLI:

1. ensures the local daemon is available
2. calls the local HTTP API exposed by `packages/platform/server`
3. hands off real work to `packages/platform/control-plane`

That makes the CLI a stable shell over a shared local runtime rather than a second product core.

## Why this is flexible

Because the CLI is thin, new product capabilities usually do not require redesigning the CLI architecture.

Most new work lands in:

- control-plane runtime logic
- source adapters
- codemode packages
- server/API surfaces

The CLI mostly needs new commands or command wiring on top of those primitives.