Terminals

The Terminals view is where agents run in the open. It is a full terminal workspace — folder-bound workspaces, split-pane grids, per-pane profiles — and every AI session in it is an ordinary, visible terminal you can read, type into, and take over. Nothing runs as a hidden background process.

Open it from the sidebar: Terminals. Open workspaces nest under the entry as sub-rows.

Terminals is a Pro surface — see Tiers: Pro & Ultra. The gate covers popped-out terminal windows too, so a torn-off pane is gated exactly like the view it came from.

Workspaces and panes

A workspace is a folder-bound, color-coded tab holding a grid of terminal panes. A pane is one terminal — a plain shell, or a grounded agent session — with its own profile (shell, working directory, startup command).

Everyday operations:

• Split, rename, swap, and drag panes; drag to an edge to dock, or tear a pane off into its own window. Pop a whole workspace out too — popped-out windows are restored on relaunch.
• Maximize one pane while siblings keep their scrollback; search inside a pane with Ctrl+Shift+F (Cmd+F on a Mac); zoom with Ctrl +/-/0 (Cmd on a Mac).
• Broadcast one command to every pane in a workspace.
• Command blocks: each command gets an exit-code and duration gutter, so you can scan what succeeded at a glance.
• Status dots on each pane header: green (running), red (exited, with the exit code), amber (needs you — a permission prompt, an idle wait, or a bell). Workspace tabs carry an open-terminal count and an unseen-stop badge.

Terminals survive view switches and window reloads — a pane re-attaches to its running session rather than restarting it.

Launch a workspace

1. Click + in the sidebar (or the new-workspace action in the view) to open the setup dialog.
2. Pick a count — 1 to 12 terminals launch at once, laid out in a balanced grid.
3. Choose what each terminal runs: a grounded agent session, a plain shell, or any command. Claude is the chip for a grounded session on the documented path, and a grounded agent run is what a mission fleet requires — a plain shell spawns bound and configured but with no dossier or role reaching it, and the dialog warns you before it lets that happen.
4. For grounded sessions, set the spawn controls:
   • Model and reasoning effort — pinned per session.
   • Skip permission prompts — on, the session acts without asking before each tool call; off, it asks for your approval first. On is the default, and it is a global default: it applies to every new workspace, including ones your agents create. Unattended work has nobody to answer an approval prompt, so leave it on for fleets and scheduled dispatches and choose deliberately everywhere else.
   • Working folder — any path on any drive, including a repository outside the install. Read Working outside the install before you point one at code you did not write.
5. Attach a Global context — optional, injected at launch, inherited by every terminal in the workspace. The picker takes context artifacts and plain file paths alike. This is the operator's half of grounding, and it is the same channel an agent uses when it launches a workspace itself.
6. Write a First message — optional, delivered once each session is ready, targeted at All terminals or Don't send. This is what turns a grounded workspace into a working one: with nothing to send, the terminals come up grounded and wait at an idle prompt.
7. Launch. Every terminal appears as a visible pane immediately.

Working outside the install

A workspace can be pointed at any folder on any drive, including a repository you did not write. Two controls decide what such a session is exposed to, and they cover different things:

• Connected or standalone. A connected session keeps the full toolkit — Command Center's tools, agents, skills, and memory — while working in that folder. A standalone session launches in the folder with none of it attached.
• MCP scope. A connected session that works in that folder offers a choice between Command Center + this project (the project's own MCP servers are merged in, if it ships any) and Command Center only (the project's .mcp.json is ignored). The second is the safer setting for a repository you have not vetted. It is offered on session types that have a per-session MCP scope flag; a session type without one always uses the Command Center server set and never merges the project's own servers, and the dialog says exactly that in place of the choice. The advanced alternative — keeping Command Center as the session's home while it reaches into the folder — is always Command Center-only.

One expectation to get right before you open an unvetted repository. Restricting MCP scope is not a sandbox, and MCP servers are not the only thing a folder can contribute. Folder trust is a separate gate, and Command Center closes it for you. When a pane starts an agent CLI, Command Center writes the trust record for that pane's working directory itself, at spawn — for both engines, at every permission mode, whether or not the Auto-trust workspace folders box is ticked. No trust question appears, because none is asked. Trusting a folder is what lets that folder's own project-local configuration and hooks load. So a workspace pointed at a third-party repository can load that repository's configuration and hooks without you reviewing them first.

This is deliberate, and worth understanding rather than working around. A scheduled dispatch or a mission fleet starts panes while nobody is watching; a CLI trust dialog in that situation is a session that hangs until someone happens to look. Command Center answers the question up front so unattended work can run at all.

The consequence is the part to plan around: there is no setting that gets you the review instead. Skip permission prompts governs the CLI's per-action prompting, and Auto-trust workspace folders pre-trusts the workspace root when you tick it — neither one stops the per-pane trust record being written. So vet a third-party repository before you point a workspace at it, and treat Command Center only as a scope restriction on tools, not as an isolation boundary. If you want to read a repository's hooks and project config first, do it outside Command Center, or in a pane that is not an agent session.

Agent panes and grounded sessions

A pane running an agent CLI is a full, interactive agent session — its own tools, model, and permissions, powered by your own agent subscription; claude is the documented path. What makes it a grounded session is context injection at launch:

• Attach context artifacts — curated notes and file references — to a whole workspace or to a single pane. A workspace-level context is inherited by every grounded pane in it; a pane-level context adds a specialist slice; the session receives the union.
• Only the context is injected. The session keeps all of its own capabilities — grounding tells it what it is working on, not what it is allowed to do.
• Grounding is set at launch. Changing the attached context set relaunches the pane so the new grounding takes effect; editing an artifact's content affects the next launch, not a live session.

Agents can open and drive terminals too, through the same machinery you use. Every terminal an agent opens is a regular, operator-visible pane — there is no separate hidden session type. This is deliberate: what you see in the Terminals view is everything that is running.

Session resume

Quitting the app does not lose your sessions' threads:

• Agent panes auto-resume. On the next launch, each agent pane relaunches its exact prior conversation, in its original pane. Auto-resume is on by default and validates the record first, so a stale session never lands you on an error prompt.
• Manual controls: a per-workspace Resume sessions (N) action, and a per-pane Resume session… picker that lists prior conversations for that pane's folder.
• Plain shells restore their scrollback so you keep what you were looking at.

The honest framing: a restart resumes the conversation, not a running program — a shell cannot resume a build that was mid-flight. Treat resume as continuity of the agent's thread, and restart long-running processes yourself.

The pause pill and the audit log

Two controls make watched delegation safe:

• The agent-control pill in the Terminals toolbar shows the live agent-session count (agent · N). One click pauses all agent terminal control: every mutating agent action — writing input, opening or closing terminals, rearranging workspaces — is refused while paused, and the pill turns amber (agent paused). Reading stays available, so you can inspect a paused fleet safely. No restart, effective immediately.
• The audit log at documents/terminal-workspaces/.control/audit.log records every mutating agent action on the terminal plane as one JSON line — timestamp, action, outcome, target, and a truncated detail. It rotates automatically. Every mutating call the plane accepts is written to it — but read it for what it is: a record of what the plane was asked to do, in an ordinary file with ordinary file permissions, not a tamper-proof ledger.

Agent terminal control can also be switched off entirely, in Settings ▸ Terminals ▸ Agent control planes — see Settings and Autonomy & controls. It reaches the same live gate the pause pill does, takes effect immediately with no restart, and — unlike the pill — is written to your configuration, so it survives the next launch. With it off, agents cannot touch terminals at all.

Mission fleets in the Terminals view

When you dispatch a mission, the fleet lands here: one workspace holding a commander pane and worker panes, each a grounded session carrying the mission's context and its role. You watch the commander decompose and assign work, watch workers execute, and can type into any pane to redirect an agent — or pause the whole fleet with the pill.

A maturity note, stated plainly: the fleet machinery is designed and built, and it is best run watched — keep the Terminals view open while a fleet works, and treat the pause pill as your first control, not your last resort.

Where to go next

• Missions Board — dispatching the fleets that run here
• Context artifacts & grounding — what grounded sessions are briefed with
• Autonomy & controls — the terminal plane alongside every other switch
• The operator model — why everything runs in the open