Local & cloud
Where local, worktree, and cloud workspaces actually execute, and what's shared versus isolated between them.
Every workspace has one execution target, chosen when you create it: your local checkout, a new worktree, or a cloud sandbox. See Choose the right workspace type for when to pick each.
Where each target actually runs
| Target | Runs on | Shared | Isolated |
|---|---|---|---|
| Local checkout | Your machine, in the repo's existing checkout | Your full local environment — installed toolchains, dotfiles, running processes | Nothing beyond git; agent edits land directly in your primary checkout |
| New worktree | Your machine, in a separate git worktree for the same repo | The same machine, disk, and installed toolchains as your local checkout | Its own directory and branch, so an agent normally edits only that worktree — but a worktree is not a security boundary |
| Cloud workspace | Your personal cloud sandbox — a remote machine running the same Proliferate runtime as local | One sandbox per person, reused across every repo you've enabled for cloud, not a fresh machine per repo or per workspace | Away from your laptop entirely, with its own disk and processes separate from any local worktree |
Terminals and browser previews run wherever the workspace runs. The file browser follows the same split: a local or worktree workspace reads straight off disk, a cloud workspace reads from the remote sandbox attached to it.
Because one sandbox serves all of your cloud workspaces, isolation in the cloud is per user, not per workspace: the cloud workspaces you own share the same sandbox, disk, and processes. The boundary is between you and everyone else, not between one workspace and the next.
Worktrees isolate workflow and branch state. They are not a security boundary. A cloud workspace isolates execution away from your laptop, which matters most for anything you wouldn't want touching your local machine.
Cloud sandboxes: wake and resume
A cloud sandbox pauses when it's been idle. Opening a cloud workspace and reading its transcript don't wake it — that history is served by Proliferate, not the sandbox. The sandbox wakes when you send it work: an agent run, a command, or a terminal action. Waking takes a few seconds while the sandbox resumes and the runtime reconnects.
Seeing "could not be reached, retry in a moment" right after sending work to an idle cloud workspace is normal during wake, not a failure. It reconnects on its own within a few seconds; retry the prompt if it doesn't.
Local and worktree disk
A worktree is created with its workspace and shares your machine's installed toolchains and dependencies. Archiving a local checkout or worktree only hides it from the active UI; it does not prune files. A cloud archive also leaves its runtime worktree in place in the current product.
Settings -> Pruning inventories Proliferate-managed worktrees. An operator can opt a runtime into retention of old, clean worktrees, or you can explicitly purge a managed workspace and its runtime history after a safety check. The linked local checkout itself is not a managed prune target. See Lifecycle & storage for the full create-to-delete flow, and Repo configuration for how setup scripts and environment variables differ between Local and Cloud.
Cloud environment limits
How many cloud environments you can run at once is capped by your plan. See Budgets & limits for your current caps.