The terminal UI

Documented against OpenRig 0.7.7. Help text uses "node" where these pages say seat, for a seat's position in the running rig.

What it is for

rig tui opens the status dashboard: the one screen where you see the whole fleet and the work it is doing without being the router between seats. The left side is an explorer over what exists: hosts, rigs, pods, seats, specs, projects, missions and slices. The right side shows the selected thing on tabs: a table, recent events, an overview, a graph, health, topology, YAML. A command bar at the top takes the TUI's commands, listed below, and ? opens a palette that fuzzy-finds every one of them. It is the surface built for a person; the CLI and the terminals are the surface built for agents. Both read the same records.

The tour on the homepage is a staged version of this screen with fictional data. The real one is what you get after rig up.

The three commands you will use first

Open it. Bare rig opens it when stdin and stdout are both terminals; rig tui opens it explicitly. To see the dashboard beside your operator, rig terminal open saved:kernel --window opens both in a new terminal window. rig tui --shared is the dashboard-only fallback when that window can't open; detach with Ctrl-b then d.

rig tui
rig terminal open saved:kernel --window
rig tui --shared

Find your way. Inside the TUI, type a rig, pod or seat name to drill into it, back to return, and tab to switch the content pane between table, recent, overview, graph, health, topology, configuration, yaml and pulse.

rig my-rig
pod dev
agent impl
tab graph
back

See the work. projects chooses a project from the workspace catalog, mission <name> opens its missions and workflows, source reads the selected project, mission or slice file, and attention (also needs or feed) shows human requests separately from outcome and health updates.

projects
mission search-experience
source
attention

Every TUI command

The TUI lists its own commands with rig tui commands (add --json for agents). The full table, generated from the current release, is the TUI command registry: every command with its aliases and arguments; the table's first line names the release. Since 0.6.6 it has gained launch, launch-folder and launch-host to start a rig spec from the TUI, reply and whose to answer requests in the Feed, and usage, usage-hosts and cost to read usage windows and reported cost.

terminal <view> opens a view in a new terminal: Rex, Herdr or plain tmux. When the TUI runs inside cmux, it opens views in cmux; the release notes say that path hasn't yet been tried in a real cmux.

What it does not do

• It does not start agents, launch terminals or resume seats by itself. The startup view starts the daemon and the seats you select only when you choose them. terminals previews a saved or derived view; opening one is an explicit action (terminal <view> here, or rig terminal open).
• It does not replace the CLI for agents. Every command an agent needs is a rig verb with --json.
• The older web UI (rig ui open) still exists, in maintenance mode with best-effort support, and is served only when ui.enabled is turned on. The TUI is the operator surface. Do not diagnose product behaviour from the web UI.
• Reading a request in attention does not approve or deliver it. Resolved settings shown under system do not prove runtime adoption.

Where it goes next

• Messaging: how seats reach each other and how you reach one seat's screen.
• Coordination: the queue rows the attention view is built from.
• Configuration: the keys the system view browses, with their defaults and sources.