Desktop App Companion

The Rollout desktop app connects a local device to your account. It runs workflow actions that need your machine: shell commands, AI Agent sessions using installed command-line tools, browser automation, and anything that should wait for your approval before it executes.

Status: Alpha (features may change).

What it enables

  • Run command node — run a shell command on a connected device
  • AI Agent node — run the selected installed agent CLI on a connected device using its local authentication
  • Run browser script node — run Playwright scripts against Chrome on a connected device; the app keeps a dedicated Chrome profile, so you log into sites once and sessions persist across runs
  • On-device approvals — review sensitive commands on the device before they run
  • Server approvals — approve or deny requests you made elsewhere (an agent's MCP invoke call, an App tool call, a workflow approval step) without opening the browser
  • Device capabilities — control what each device offers to workflows
  • Published Apps — open Apps you have access to, including Apps pinned to Home

Device actions can also be exposed to agents through reviewed Tools.

Connect a device

  1. In the app's Connections page, add a server and connect. Connections without a saved token open a browser login
  2. Log in (or sign up) in the browser
  3. Choose the workspace the device should work in and confirm the authorization
  4. The browser hands the authorization back to the app, which stores the token in the OS keychain

The device authorization stays bound to the workspace you picked. Use the Test button on a connection to check whether the server is reachable and the token is still valid.

Registered devices appear under Settings → Devices in the web app, where you manage sharing, workflow capabilities, and removal.

Device capabilities

Capabilities are detected on the device; only detected capabilities can be enabled. Toggle them in the app's Settings tab or on the Device settings page inside the app window:

  • Command
  • Claude Code
  • Codex
  • Browser automation
  • File read
  • File write
  • Filesystem
  • Screenshots
  • Audio

Workflows can only use capabilities enabled for the device. The workspace can further restrict what workflows may use per device under Settings → Devices.

Concurrent jobs

A device runs at most 16 jobs at once. Every command a device accepts draws from that one pool: shell commands, Claude Code, Codex and browser automation. There is no separate allowance for read-only work. The limit is fixed in the app and cannot be changed locally or by workspace policy.

Task workflows add a second limit. A task pointed at a device holds it for the whole turn, so one task implementor runs per device at a time. A second task aimed at the same device waits for the first to hand back, whichever runtime or permission mode it uses.

Neither limit fails work. A command that arrives while the device is full goes back to the queue and is delivered as soon as a slot frees. The workflow step waiting on it keeps its own timeout running, so a device that stays full long enough will still time the step out.

The Device settings page inside the app window shows both numbers.

Targeting a device

Each client node has a Device section:

  • Target Device — the user's default device, any available shared device, or a specific device
  • If No Device Available — fail the step immediately, or queue the command until an eligible device connects
  • Timeout — maximum wait for a finite command phase (10–5,400 seconds, default 300); node and workflow execution limits also apply

See Client Workflow Nodes for subscription CLI setup, explicit session continuation, structured review, and recovery limits.

Approvals

  • Client commands require approval on the device by default; each node's Approval Required setting controls this, including a Never option for trusted automations
  • Set an Approval Message on the node to explain the request in the approval card
  • Approval cards show the command, workflow, and metadata; approve or reject with an optional reason
  • Consent-required commands always wait for a fresh decision acknowledged by the server. Saved local policies do not bypass that receipt.
  • The app sends system notifications for new approval requests and finished or failed tasks
  • An optional Approval Timeout on the node fails the step when a prompt goes unanswered

Each prompt for a consent-required command is tied to one connected device session and one exact command. Approving or rejecting sends a decision to the server; the app waits for the server's acknowledgement before it starts the command. A disconnect before consent can require a fresh delivery and prompt. After positive consent, a disconnect with no result leaves the outcome unknown and does not automatically run the command again. An expired request, changed command, or withdrawn execution authority cannot use an old prompt. Device admission requires the current approval-receipt protocol. Device consent is separate from any manager approval required for a capability.

Server approvals

Requests that the Rollout server runs appear in the same Activity list with Approve and Deny: an agent's invoke call, an App tool call that needs approval, a workflow approval step, or activation of an MCP-authored tool. You see every pending request you started yourself, plus every request Rollout notified you to review. A request from an agent shows the same short code the agent received, so you can match the card to the call you started. Open in Rollout opens the request on the web. Cards arrive only for the workspace the app is currently connected to, and disappear when their deadline passes or when someone decides them elsewhere.

The server checks your current permissions when you decide, exactly as it does on the web; a card you cannot decide says who has to. A decision is recorded as made in the desktop app. Server approvals are separate from device consent: approving an MCP invoke call never lets a command run on this device.

The pending list is a local transport cache; the server keeps the decision history. An execution status saying “executing” does not stand in for your decision. Temporary execution files and credentials become available only after the server has acknowledged approval.

App window and tray

The app lives in the system tray / menu bar:

  • The tray menu shows connection status, pending approvals, running tasks, a Connections submenu for quick server switching, and Open Rollout, Device Settings, Disconnect, and Quit items
  • Tray items open the Activity panel (pending approvals, running work, and this session's activity), Connections page (servers and logins), or Settings page (device identity, capabilities, shortcut and update controls)
  • This session lists what happened since the app launched, for the connected workspace, newest first: every approval or rejection you made here (on-device commands and server requests, with the request's binding code) and every finished run with its outcome, duration and output. A summary line counts runs and decisions by outcome. Reconnecting keeps the list; switching workspaces shows that workspace's activity instead. Nothing is kept after the app quits.
  • The panel keeps its window size across pages. Resize it to suit your display; its content scrolls beneath the header
  • Open Rollout (or your configured launcher shortcut, Option+Space on macOS by default) opens the full Rollout app window — dashboard, messages, tasks, projects, and docs — signed in as this device

Application updates

Settings shows the installed version. Builds with a published signed update feed check for updates after startup and every six hours; Check for updates runs a check immediately. Install and restart downloads and verifies the package, then waits for running work, result recording and pending approvals to finish. It never installs automatically.

When release signing and hosting have not been configured for your build, Settings says updates are unavailable. Install a newer build from its DMG. The DMG is the initial installer; in-app macOS updates use a signed app archive.

Security notes

  • Commands require manual approval on the device by default
  • Use specific device targeting for sensitive workflows
  • Tokens are stored in the OS keychain, never in plain files
  • Remove a device under Settings → Devices; it disappears from the workspace until its client re-registers. Disconnect or delete the connection in the app to stop it from executing commands
  • Treat device capabilities like production credentials: enable only what a workflow or agent should use

The server limits concurrent agent turns per device (max_agent_turns, default 4). Owners and exact Managers edit it in Settings › Devices or MCP. Parkable graph steps wait without an execution timeout, then resume in FIFO order among runnable turns. Tool calls, App/MCP calls, session and iterated agents cannot queue: a full device returns device_busy immediately. Shell commands and the desktop protocol keep their existing behavior.