The Command Bar

The command bar is row two of the Floor, and it is the only dispatch entry point in the product. Every agent session starts here — there is no second ask field hidden in a panel, no auto-launcher deciding for you. You state what you want built, and you press Dispatch.

Left to right

• › lead glyph — marks the ask line.
• The ask — a text field with the placeholder “Describe what you want built…”. It grows with what you type; the bar grows with it. Enter dispatches.
• CODE / PLAN — a segmented control choosing the dispatch mode: build it now, or shape a plan first.
• Model chip — shows the session’s model and opens a picker listing the models your connected providers offer. Switching notes: “Context and worktree carry over.”
• Effort chip — the reasoning-effort level, when the harness offers one (see below).
• Dispatch — labelled Dispatch ↵, the row’s single filled button.

When Dispatch is dormant

The Dispatch button’s fill is withheld — not greyed out with a fake disabled state — in exactly two cases that look the same and mean different things:

1. Nothing is typed. There is no ask to commit.
2. The app already knows it would refuse. For example, a claim held by a teammate, or a capability the harness has not granted.

If the button has its fill, pressing it starts a session. If it does not, the app is telling you the commit would not go through.

Capability-gated controls

The command bar only offers controls the active harness adapter actually honours, read from the adapter’s capability manifest:

• No effort chip if the adapter declares no effort levels. A harness that would silently drop the setting is never handed a control for it.
• No slash-command picker if the adapter has no command catalog on disk or does not declare that it honours one. Typing / in the ask opens the picker only when both are true.

Where the manifest states a limit, the menu carries that note verbatim rather than paraphrasing it.

Note

This gating is what keeps the product honest about being model-agnostic: a future adapter for another provider does not inherit Claude Code’s conventions by accident — it gets exactly the controls it declares.

Adding a project

Adding a project happens here too — there is no add-project dialog. When you choose Add project (from the project menu), a bone “Add project” chip re-enters the ask line and the field asks for “path to a repo, or a git URL”. The flow has four states:

1. Awaiting path — the chip plus the input. Enter submits, Escape cancels.
2. Resolving — a spinner with the path echoed in full: “Resolving <path>…”.
3. Setup — the path resolved to a repo: “Resolved <path> — continuing into project setup.”
4. Terminal branches — already initialised (an inline notice: the project is already set up) or not a repo (your typed text is kept, the reason is stated in full, and you can Edit and retry or Initialise a repo here).

If you start leaving with an attempt half-finished, the bar says so — “This add-project attempt is not finished — leaving discards it” — and offers Keep editing or Discard.

After dispatch

A dispatched ask becomes an agent on the roster, and its session lands on the stage. Replies to a running agent go through the session’s own reply bar on the stage — the command bar is for starting work, not continuing it.