Run kestrel or its ks alias to open the interactive terminal client. The
client connects to Local Core, so sessions, runs, events, and terminal results
use the same durable execution model as Desktop.
kestrel --profile kestrelStart in the intended workspace
From a project folder, inspect the binding before opening the client:
kestrel workspace status
kestrel --profile kestrelInside the client, /status shows the active profile, session, workspace,
mode, waiting state, and relevant tool configuration. Do not infer those values
from a sample prompt or folder name.
Choose interaction mode
Use the visible typed control to select Chat, Plan, or Build. The mode is explicit operator intent and remains visible with the session; Kestrel does not silently infer it from the wording of a prompt.
Sessions and history
Use /sessions, /switch, /resume, and /new to move among durable local
sessions. Closing the terminal does not erase the recorded session or its runs.
Local Core owns their persistence under the platform-specific state root
described in Command suite.
Operator control
These commands act on recorded work rather than creating an unrelated session:
| Command | Purpose |
|---|---|
/status | Inspect the current session and wait state |
/resume <name> | Continue a saved session |
/reply <message> | Answer a pending interaction |
/approve or /deny | Resolve a pending approval |
/steer <message> | Add durable guidance to focused work |
/retry [reason] | Retry through operator control |
/stop [message] | Cancel active work and record the operator action |
/operator | Open operator-focused inspection and recovery commands |
Inspect before acting so a reply, approval, retry, or cancellation stays attached to the correct run.
Waits and recovery decisions
/reply, /approve, /deny, and recovery actions answer the exact pending request. Select recovery by its stable option identifier when one is offered; inspect before acting so stale terminal scrollback cannot authorize the wrong work.
Mission Control
Use the project/task views for Mission Control work items, attempts, evidence, review, and acceptance. Keep those project decisions separate from /retry, /steer, or /stop runtime control.
Activity and progress
The terminal keeps conversation content separate from runtime and tool
telemetry. Provider-exposed reasoning is live-only by default. Validated
run.agent_progress events can become durable progress, while generic
run.progress events remain runtime diagnostics.
Profiles and tools
Use /profiles, /model, /mode, /code, and /mcp to inspect the current
configuration. These controls change runtime behavior and tool availability;
they are not display preferences.
Read Profiles, code mode, and MCP before creating a custom profile, and Operator control workflows for server-side equivalents.
Terminal outcomes and exit behavior
The conversation ends each accepted operation with a completed, failed, cancelled, or waiting outcome. Scrollback/reconnect may render persisted events again, but it must not create a new run or duplicate the committed assistant message.