Skip to main content
Multi-workspace mode gives every user a private personal workspace and lets members of an organization share team workspaces. Each workspace is a complete context: its own files, chats, AGENT.md and key-value store. A team workspace also has its own skills.
It requires auth, since workspaces are keyed on the authenticated user.

​
The model

Every organization gets General on its first request. Solo users without an organization get a personal workspace only. Team roles are owner, who created it and can delete it, admin, who manages members and renaming, and editor, who works in the workspace. The owner row cannot be changed, and members can always remove themselves.

​
In the web client

The workspace menu in the navbar switches between Personal and the team workspaces, and creates new ones for whoever create= allows. On small screens it sits in the avatar menu. Owners and admins of a workspace get a members button beside it that opens Settings, Workspaces on that workspace. Members, roles, the name, the icon and deletion are managed there. Lists of people load everyone in the organization, not only the first 10, and someone who has left it shows as Former member. A search box appears once a list has more than 8 people, and the organization’s Members table in Settings shows 20 at a time with Show more. Each workspace keeps its open chat and canvas tabs while the page stays open, so switching back finds them as they were.

​
Selecting one

The client sends the active workspace in an X-Workspace header on every request. No header means the personal workspace, so existing API clients keep working unchanged.
Unknown or unauthorized ids return 404 rather than 403, so ids do not leak existence.

​
Inside the agent

context.workspace resolves to the active workspace. The bash sandbox binds only that workspace’s directory at /workspace, and uploads, the canvas and AGENT.md all follow it. Skills come from the agent, the organization, the team workspace and the person, whose own follow them into every workspace. Chats and the database tool stay per user within a workspace. Teammates share files, not each other’s conversations.

​
HTTP API

Mounted only when workspaces are enabled. All routes require auth. Adding a member takes their user id from the identity provider. The row alone grants nothing: access also needs a valid token for the same organization, so a stray id is inert.

​
Turning it on for an existing deployment

The SDK moves no data. On an organization’s first request it creates General’s registry row and nothing else. Existing content under the organization root stays where it is and is invisible in workspace mode until an operator migrates it. Solo accounts need no migration at all, because their personal workspace is the account root.

​
Security notes

The bash sandbox binds only the active workspace at /workspace. Sibling workspaces are not mounted. Registry and ACL rows live outside every workspace root, out of reach of both the sandbox and the path-validated file tools.
AGENT.md is per workspace, so in a team any editor’s instructions run in teammates’ sessions. It is the same trust boundary as a shared repository, and worth saying out loud to your users. Skills are narrower: only a team workspace’s owners and admins publish its skills, and only org admins publish the organization’s.
A deliberately adversarial user with network-enabled bash can reach the deployment’s own credentials. .sandbox(network=False) closes that path.

​
Next

Monetization

Plans, quotas, and in-app purchase entitlements.