sharing

Sharing and slots

Workflows and Crews can be shared with other people; Code is always private to its owner. Sharing is decided in one place and enforced in two layers: the server authorizes who may, and the person's isolated account decides what their processes can touch.

Who may do what

OwnerFull control: run, edit, share, delete.

→

EditorRun and edit. Can't share or delete.

→

ReaderRun and view. Can't change anything.

Each workflow carries its own list (owners, editors, readers); admins keep owner-level access everywhere. Every access is re-checked when it happens — including scheduled runs that fire while you are away. Removing someone stops all their new access immediately.

What shared access can touch

When Bob runs Alice's shared workflow, his agent steps work and his shell steps don't — by design, in this order:

Server decides

Bob is a reader of Invoices.
Launch policy lists exactly the shared folders, read or read/write.

Agent steps ✓

Bob's account is granted just those folders for that launch.
Nothing else on the host opens up.

Shell steps ✗

No grant step exists yet: Bob's account meets someone else's folders and is refused.
Fails closed, loudly.

Shell access to shared folders is the known gap: it fails with "permission denied" rather than leaking, and extending the grant step there is planned work. Agent runs — the common case — are unaffected.

Code stays out of this

A Code workspace has no readers, editors, or shares: only its owner opens, runs, or edits it. One Code can call explicitly declared functions on another Code its owner also owns, and audited read-only inspection exists separately for admins and reviewers. There is no cross-user Code folder to mount and no Code credential to share.

Related: Per-user Linux accounts, Provider credentials, Security overview.