Workspaces and execution

A workspace gives a task its project context and policy. It can refer to repositories and constrain which models a spawned task may use.

Configure the registry

The runtime reads ~/.condensate/workspaces.json, or CONDENSATE_WORKSPACES_FILE when set. A minimal registry has workspace names, repository references, account names, and policy.

The registry is schema-validated. The runtime checks file identity and rereads it when it changes, so editing the registry does not inherently require restarting the runtime. A spawn that names an unregistered workspace is refused before creating the task.

This example uses placeholders. Replace my-repo and my-account with registered repository and account names before using it:

{
  "workspaces": [{
    "name": "my-project",
    "repos": [{ "name": "my-repo", "writable": true }],
    "accounts": ["my-account"],
    "policy": { "maxSeats": 2 }
  }]
}

curl -fsS http://127.0.0.1:4741/workspaces

Use this read to verify what the running runtime sees. Do not infer its registry from a similarly named file in another checkout.

Keep project identity separate from execution

A workspace is not a machine. The runtime has a local process runner and a Kubernetes runner implementation. Runner selection is policy-controlled and depends on supported capabilities and configuration.

The presence of Kubernetes code does not mean a fresh checkout has a cluster. Mac-only tools, credentials, filesystem access, and runner readiness must be checked before moving work. Use the process path for the basic local setup.

A workspace head

A head is a coordinating thread with a distinct role. The runtime enforces head identity and exposes children and subscriptions through its normal event and thread APIs. A child task remains its own durable thread.

Changing an execution session, an account, or a model should preserve the durable task history. Back up the log and engine state before changing the storage layout.