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.

Workspaces and panes

A workspace is a folder-bound, color-coded tab holding a grid of terminal panes. A pane is one terminal — a shell, or a grounded Claude 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; zoom with Ctrl +/-/0.
• 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–12 terminals launch at once, laid out in a balanced grid).
3. Choose what each terminal runs: a grounded Claude session, a blank shell, or any command.
4. For grounded sessions, set the spawn controls:
   • Model and reasoning effort — pinned per session.
   • Permission mode — a toggle that lets sessions run with tool prompts skipped. On means unattended execution (the session acts without asking per tool use); off means Claude asks before tool calls. The dialog explains the trade-off; choose deliberately, especially for fleets you intend to leave running.
   • Working folder — any path on any drive, including a repository outside the install. A session there can stay connected to the full toolkit (tools, agents, memory) or run standalone; for an untrusted repository, an option restricts the session to Command Center tools and ignores the repo's own tool configuration.
5. Launch. Every terminal appears as a visible pane immediately.

Agent panes and grounded sessions

A pane running Claude is a full, interactive Claude Code session — its own tools, model, and permissions, powered by your own Claude subscription. 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. Assume everything an agent does to a terminal is on this log, because it is.

Agent terminal control can also be disabled entirely in the configuration if you want a session where 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
• The operator model — why everything runs in the open