Workspaces & envs
Two primitives carry most of the model: a workspace is your team's home, an env is the unit of work. Almost everything else hangs off these two.
Workspace
A workspace is a tenant. It owns members, billing (eventually), repositories, and policies. Most teams have one workspace per company; large orgs may have one per division.
- Members have roles: owner, admin, developer, viewer.
- Repositories are the Git remotes the workspace can clone into envs.
- Policies configure the agent gate (which checks must pass before merge).
Env
An env is one isolated workspace where work happens. It maps to:
- A Docker container with the cloned repo.
- A Git branch (created on demand).
- A Claude Agent SDK session, shared across all current viewers.
- A chat history and a terminal stream.
Lifecycle
- Created — the API boots the container, clones the repo, primes the agent.
- Active — humans + agent collaborate. Branch evolves with each accepted change.
- In review — agent gate runs. State is frozen until the gate passes or fails.
- Merged — branch opens a PR; CI/CD takes over. Container is reaped.
- Discarded — env can be archived at any time. Branch is preserved if marked.
Sharing
Envs are shared by default within the workspace. Anyone with the link who is a member can join. Permissions inside the env follow the member's workspace role: viewers can watch the chat but not send prompts; developers can prompt the agent and edit files; admins can force-stop or merge.
Why not just branches?
Branches don't carry context. An env wraps a branch with the chat, the terminal, the running app, and the agent's memory of the conversation so far — making it possible for non-technical teammates to drop in and contribute meaningfully.