Desktop clients

A desktop app should treat Roder as a local harness process and speak the app-server protocol. The desktop owns windows, terminal panes, web views, file drag-and-drop, and OS affordances; Roder owns turns, providers, tools, policy, sessions, and events.

Expected desktop shape

• Main process starts roder app-server over stdio.
• Renderer uses typed protocol methods for sessions, turns, tools, providers, and approvals.
• Transcript, tool timeline, diff viewer, command palette, terminal, and browser panels render app-server state.
• Provider selection and reasoning settings persist through app-server config methods.

Why this boundary

Desktop clients need native affordances, but they should not fork the agent runtime. Keeping the harness in Roder lets the TUI, desktop, and automation surfaces share sessions and feature work.

Remote controller path

Remote mode keeps desktop and TUI clients on the app-server client abstraction. A local controller can connect to a remote Roder node, render the remote runtime's threads and notifications, and leave sessions, tools, commands, provider auth, and artifacts owned by the remote machine. Sprites-hosted nodes use the same remote app-server transport.