Access & sharing
A sandbox has one owner and any number of invited people, each on a tier that decides what they can do. The daemon enforces it: the tiers are not a UI convention.
On this page(8 sections)
How the owner is decided
Trust on first use. The first verified identity to reach a new sandbox becomes its owner, and the daemon remembers it. The platform cannot name one for you: it holds your identity and your sandbox's address, and has no way to reach in.
With Google, sign-in is directly against Google: your browser presents an ID token and your sandbox verifies it against Google's published keys. The platform never holds or signs that credential.
An address that no identity provider vouches for, on your own domain or a company mail server, signs in with a code the platform mails to it. The platform then signs a short-lived assertion that you control the address, for one sandbox, and the sandbox checks that signature. On a sandbox on your own machine it accepts one only for an owner who first signed in to it by email, or for a person you allowed to sign in by email when you invited them. So a platform compromise can reach only those people's access, never an owner or member who signs in with Google. On a machine we host, the platform already holds the machine, and an assertion is accepted for anyone on the roster.
A passkey removes the platform from the path. Passkeys belong to the sandbox, keep working while the platform is down, and are suggested right after a first email sign-in. Turn on Require a passkey to open this sandbox and the platform's word alone opens nothing.
The tiers
| Tier | Can |
|---|---|
| Guest | Talk to the persona cards the owner picked for them, and only through those. See no files, no other conversations, nothing of the box. The tier for someone who needs answers from the workspace, not the workspace: what they reach is exactly what their cards carry. |
| Viewer | Watch everything: agents, chats, files, the workspace. Change nothing. Safe to be generous with: every read is attributed and nothing it can do alters the sandbox. |
| Collaborator | Drive agents and review their work: start turns, answer questions, steer, stop, rename, archive. Agent work stays on isolated branches, so driving one changes nothing in your tree. Landing and publishing become requests instead. |
| Writer | Everything a collaborator can, plus changing files themselves, inside the areas they hold. Nothing they change leaves the sandbox on their say. The tier for someone who works on one part of the project. It always comes with at least one area. |
| Maintainer | Ship and operate: land work, approve drafts, use the terminal, read the logs and the connected services. The tier for anything that leaves the sandbox. |
| Owner | Everything, plus the things that never delegate: secrets, members, control tokens, approving an image rebuild. Exactly one identity, bound at first sign-in. It cannot be granted. |
They draw real fences rather than mirroring the navigation:
- A guest sees only their own conversations. The fleet, the files and every other transcript are refused to it by the daemon, and each of its turns wears one of its cards.
- Credentials stay with the owner. Invitees cannot see secrets, their names or their inventory.
- What leaves the sandbox needs a maintainer. Landing into the main tree, publishing, the raw terminal.
- Collaborators can drive agents. Viewers can watch the fleet and read files and transcripts.
- A writer changes files only inside their areas. Every file route outside them refuses, and so does their agents' checkout.
Areas: giving someone part of the workspace
A tier says what someone may do. An area says where: a named set of folders, defined once under Sandbox → Areas and picked per person on this tab. Someone holding areas sees only those folders in the file tree, in search and in the conversations they can open, and can use only the personas homed inside them. Their agents inherit exactly that: a conversation keeps the areas of the person who started it, and each of its turns runs with nothing else of the tree on disk.
Holding no area means the whole workspace. A writer and a guest must hold at least one; a viewer or collaborator may; a maintainer cannot, because that tier already holds the owner's operating authority. Sandboxing draws how areas sit inside a sandbox, and when someone needs a sandbox of their own instead.
Inviting someone
Sandbox → Access, owner only. You give an email address and pick the tier; Collaborator is preselected as the one that is safe to hand out without thinking and useful enough that nobody feels locked out. Re-grading someone later is the same control on their row.
A grant is written to your daemon first and recorded on the platform second, so a grant the enforcer never received is never recorded anywhere. It fails closed. Removing someone is the same list.
Roles are resolved on every request instead of only at sign-in, so a role change or removal applies on that person's next action, not whenever they next open the app.
What people see about each other
Everyone sees who is here now: a live roster of connected browsers with the view each is on, the conversation they have active, and whether they have gone idle. Presence is per tab and lasts as long as its connection, so there is nothing to time out. Each person's tier is on the roster too, so everyone can see who may do what and a tab knows its own role without asking a question only the owner may ask.
When a member is refused
The daemon answers a member below a route's tier with a refusal that names the tier required, so the app can say "ask a maintainer" rather than failing blankly. An unlisted read defaults to viewer and an unlisted change to maintainer, so an unclassified route can under-serve a collaborator but never hand one a power by accident.
Programs, not people
Programs without a sign-in, such as CI jobs, editor bridges and scripts, use a control token instead of a role. The owner mints them under API tokens on this same tab, choosing a scope that maps onto the tiers above (readsees what a viewer sees, drive does what a collaborator does, land may also merge) and how long the token lives. The tab lists every token with its scope, expiry, last use and who minted it, and revokes them one at a time. Under it, Other ways in counts the sandbox's remaining doors that are in use, webhooks, release gates, CI notifications and paired devices and runners, and names where each is managed; a door nothing uses is left off. See authorising a call.
If you lose a laptop
Sign out everywhere re-keys the session signer, so every session stops verifying at once, including your own, which re-establishes from the sign-in your browser still holds. That is what makes it a button rather than a support procedure. Control tokens are revoked separately, per token, because programs hold them.
Related pages
- Sandboxing: machine, sandbox, area and agent, from the outside in.
- Parallel agents: why a collaborator driving an agent can't disturb your tree.
- Your own machine: connecting a computer, and the editor bridge.
- Guide: reviewing what an agent wrote: what to read first in a diff, and where a check command earns its keep.