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

The planned agent-node mode keeps desktop and TUI clients on the app-server client abstraction. A local controller connects to a remote Roder node, renders the remote runtime's threads and notifications, and leaves sessions, tools, commands, provider auth, and artifacts owned by the remote machine.