GenerateSaaSShared automations
A definition one member writes and every member can choose to run on their own machine - what it stores, how turning it on works, and why consent is the only gate on it.
A member who ticks Share with your workspace on a coding-CLI automation stores a definition on the backend: a name, prompt and cadence with no model. Every member sees it; nothing runs until one of them turns it on for their machine.
A shared definition is one row on every list, never two. On a desktop it is the definition carrying that machine's own run state, with a Shared badge; its switch is that machine's switch.
Once on, it is theirs: it runs on their machine, on their CLI subscription, in their connected folder, and costs nothing. It fires on the same terms as any other automation here - while the app is open, and after the window closes only on a build that ships background mode with the user's switch on.
| Row state | What the sub-line says |
|---|---|
| Running here | Running on this machine, on the CLI you chose. |
| Not running here | Shared with your workspace. Turn it on to run it on this machine. |
| Author changed it | A Changed by its author badge, plus the review note. |
| Author paused it | The author paused this shared automation... - the switch is refused. |
The row reports the viewer's own last run, labelled Last run on this device - a definition has no single last run, because it runs per member on per-member machines. A machine that does not run it sees Never run on this device. The server never fires a definition, so its own run fields are always empty.
Switching the row off pauses that machine's copy and keeps it: the CLI choice and the run history survive, and switching it back on re-arms the same automation. Delete removes the definition from the whole workspace.
On the web there is no daemon, so the row states that it runs on the desktops where members turn it on, and offers no Run now.
Editing the definition afterwards bumps its version - the row then shows Changed by its author and offers Use the updated version. Each machine keeps running the version its member agreed to until they take the new one.
Pausing or deleting a shared automation
Both reach a member's machine when their desktop app next opens - the app is what sees the workspace, and the on-device runtime holds no backend connection of its own.
| Action | Effect on members |
|---|---|
| Disable | Nobody new can turn it on. Machines already running it are paused on next open, labelled with who paused them, and the member's own switch is refused while it stays off. |
| Re-enable | The switch works again. A paused copy does not restart itself - it runs on the member's machine, so the member restarts it. |
| Delete | Removed for the whole workspace. Copies already running keep running: they are the members' own automations now, on their own disks, and nothing here reaches them. |
Turning a shared automation on is the trust boundary, and there is no role gate on it: any member can author a prompt every other member is invited to run on their own filesystem. Consent is what makes that safe - the prompt is read before it is taken, the choice is per machine and never automatic, and each fire is judged against that member's own folder grant.
Automated agents
On-device prompts that run on a cadence - the built-ins you ship, the ones end-users create, and how to keep them firing with the app closed.
Integrations
The desktop app's Integrations tab - the same backend-owned connections the web app makes, connected in-app with any provider sign-in opening in the system browser.