Skip to main content

Workspaces

A workspace is a place to file projects. Not an ownership boundary — every member of the team reads every workspace, and that is the product decision, not an omission. /workspaces is a flat alphabetical list: workspace name, project count. Selecting a row switches to that workspace and opens its Projects view; the gear beside it opens its settings without navigating.
Any member can rename any workspace. Any empty workspace can be deleted, with confirmation — move its projects out first.
Your workspace selection in the dashboard persists. A missing selection falls back to the oldest workspace by creation time, or All when none exist. The server creates a generic default only when a write needs one and none remain — deleting the last workspace does not itself create one.Subprojects inherit their parent’s workspace. An explicit destination is validated, never silently replaced with the default.

Each computer’s workspace

New projects made on a computer go into that computer’s workspace — for the CLI, the Probe daemon and SDK runs alike. The setup wizard asks “Where should this computer’s work go?” during install. Change it any time:
PROBE_WORKSPACE, or workspace= in probe.init, overrides it for one process or call. When a new project names no workspace, a team with exactly one workspace files it there. With several, the server refuses with workspace_required rather than guessing. The SDK raises WorkspaceRequired; set this computer’s workspace and run again. Subprojects need no workspace: they go where their parent is.

Who may edit

Reads are never restricted. Writes can be. Writers are named by access group — a named set of people, so the list is maintained in one place rather than per workspace.
writers set replaces the whole write state in one call, so two admins editing at once cannot interleave into a state neither asked for. Restricting with no writers at all is allowed and means nobody may edit. A workspace can be born restricted in one call rather than in two with a window between them. Enforcement is both app-layer and row-level in the database, so a bypass of one is not a bypass of the pair. The CLI is the current admin surface for this.

The team

/team holds members, invitations and roles. Invited people receive an email and land in onboarding, where their first workspace is created. Revoking a teammate’s API token is a dashboard action — probe token revoke only covers your own.

Settings

/settings has three sections:
  • Devices — every machine holding a credential for this account, with what it is paired for and whether it captures sessions. That is where a lost laptop is de-authorised.
  • AI agents — every coding agent you connected through agent sign-in, with when it connected and was last used. Revoke cuts one off.
  • Preferences — per-person choices, such as Workspace canvas, which turns the canvas on Projects on or off for you.
Workspace management deliberately lives in its own place rather than under Settings, because the two get confused: Settings is about you and your devices, /workspaces is about where work is filed.

Onboarding

Browser onboarding creates your first workspace: a team’s creator sets one up before installing, and an invited member creates one after joining. Nothing is filed by age — work goes where each computer’s workspace says, as above. Joining a team with no workspace at all still gets a generic fallback.

Privacy and terms

/privacy is live and states what is collected, including product analytics. Deletion is described as deletion, not as a purge of every derived copy — the policy says what actually happens.

Core concepts

Where workspaces sit relative to projects, experiments and runs.