Repos, views and environments

A workspace in Isolation is how one member works: the repos to clone, the views a session opens by default, the named environments it can launch with, and the agents that ride into every session. It lives inside your organization, because that is where the servers and the bill are, but it is yours. A teammate cannot open it, list it or launch it.

When you launch a workspace you get a session: an isolated sandbox on one of the organization's servers with the repos cloned, the environment loaded and the agents inside, on its own branch. Finish the session and the sandbox is gone. The workspace stays.

What a workspace holds

Nothing about a server is stored on the workspace. You choose the target when you launch, a Connected Server or a Cloud Server, and the same workspace runs on either.

Repos

A repo entry is a URL and, if you want it, a folder. Two repos clone side by side under /workspace, so a session of a full-stack workspace has the API and the frontend next to each other in the same terminal, the same code view and the same agent conversation.

A private repo needs a credential. You can rely on your personal Git credential, or set a token or SSH key on the repo itself. Either way the secret is encrypted before it is stored, is never returned to the browser, and reaches the sandbox sealed to the server that runs the session. Reading the workspace back shows only that a token exists.

The repos you clone keep their own git history and remotes. Everything around them, notes, scripts, generated files, is the workspace tree, which travels with you. Nothing lives in the sandbox explains where that tree is kept.

Creating and editing one

From the website you fill in a form. From a chat app or an MCP client you call the same action:

/new-workspace shop-api
/workspaces
/launch shop-api in staging on office-1 as checkout-fix

workspace_create takes a name, the repos and the environment names; the first environment is the default and, if you name none, it is called development. workspaces_list answers with what each workspace clones, which environments it can launch with and how many agents ride along. workspace_update edits the definition: the name, the repos, the environment list, the agents. It accepts the rev you read the workspace at, and refuses with the current definition if someone changed it underneath you, so an editor never overwrites a save it did not see.

Two rules protect your values. Leaving environments out of an update keeps the ones you have. Dropping a name from the list deletes that environment together with every variable and secret file in it, so rename with environment_rename rather than by editing the list.

Views and agents

Default views are a starting point, not a cage. In a running session you open and close views freely, and the session screen can sync the layout back to the workspace so the next launch opens the way you left it. The five kinds and what each one does are in views: terminal, code, files, web, agent.

The agent roster follows the workspace, not the session. Each agent on it gets a conversation per session and a memory per (workspace, agent) that survives finishing, so the agent you talk to about shop-api next week remembers what it learned about shop-api this week. How to write one is in define an agent.

Deleting a workspace

workspace_delete removes the definition, every environment value including the encrypted secrets, and the stored file tree. It is irreversible. Sessions already launched from it keep running until you stop them, so stop them first if you mean to.