AGENT.md, skills and key-value store.
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.
Selecting one
The client sends the active workspace in anX-Workspace header on every
request. No header means the personal workspace, so existing API clients keep
working unchanged.
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, AGENT.md
and skills all follow it.
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
Sandbox isolation
Sandbox isolation
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.Network-enabled bash
Network-enabled bash
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.