# 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](per_user_linux_accounts.md),
[Provider credentials](provider_credentials.md),
[Security overview](README.md).