TUI

roder-tui is the reference terminal client. It usesRatatui andcrossterm, but it talks to the runtime through the same local app-client path a desktop or automation client can use.

What it shows

• Streaming assistant output and tool-call timeline.
• Approval prompts and policy-mode state.
• Provider, model, session, command, policy, and agent-mode choices through the command palette and composer title.
• /agent-swarm and /swarm commands, live child-count progress, and compact ordered result grids for parallel agent work.
• Composer mention pickers for workspace files with @ and skills with $.
• Knowledge browsing through /knowledge commands and command-palette entries.
• Media generation palette entries for image and video prompts, with artifact rows in the timeline.
• Remote-node authority banners when the TUI is controlling a full runtime on another machine.
• Diff previews for file changes with keyboard-driven accept/reject handling.
• Dynamic workflow trigger hints, approval previews, and run progress below the composer.
• Shell and exec sessions as one timeline entry, with streamed stdin updates folded into the open detail view.
• Native terminal progress indicators while turns run, pause for approval, or fail.
• Roadmap orchestration panels for plan rows, task status, worker activity, and validation evidence.
• Status segments contributed by built-ins and extensions.
• Mouse selection, scroll, hover, and clickable timeline interactions as they land.

Why it is a client

The TUI should not be the only owner of runtime state. Keeping it as a client ofroder-app-server means terminal, desktop, test harness, and future IDE surfaces can share protocol methods and event semantics.

Agent-swarm mode follows that rule: the TUI toggles per-thread runtime state and renders app-server events rather than owning a separate client-only mode. Entering swarm from a gating policy asks for the required policy switch before work starts.