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(7 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.
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, so a platform compromise cannot command your sandbox.
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. |
| 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 four 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.
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, webhooks, release gates and CI notifications, and names where each is managed. 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 Google credential it 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
- 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.