Lifecycle & storage

A workspace has state at two different layers:

• Runtime state in AnyHarness: the authoritative workspace record, sessions, ordered events, transcript, and local agent artifacts.
• The checkout: files in a linked local folder or a Proliferate-managed worktree, on your machine or in your cloud sandbox.

Cloud adds a third layer: a control-plane product record for identity, lifecycle, routing, and read projections. Those projections let product surfaces load Cloud session and transcript data without waking the sandbox, but AnyHarness remains the source of runtime truth.

Removing a managed checkout can preserve runtime history. Purging a runtime workspace does not. Keep those operations separate.

Creating a workspace

What creation does depends on the target:

• Local checkout: registers a folder you already cloned. Proliferate does not create or own that checkout.
• New worktree: creates a managed git worktree and branch on your machine, then runs the repo's Local setup script.
• Cloud workspace: prepares or reuses the repo's base clone in your personal sandbox, creates a separate managed worktree and branch for the workspace, then runs the Cloud setup script.

All three expose the core chat, terminal, file, and git-review surfaces. Their wake, isolation, authentication, and storage behavior still differ.

Cloud creation reports provisioning state while the sandbox and worktree are prepared. If setup fails, the workspace remains visible with the failure so you can retry or recreate it.

Archiving

Archive currently means "remove this workspace from the active UI," not "delete it" and not "free its disk space."

• Local checkout and worktree: Desktop records a local visibility preference. The runtime record, sessions, transcript, and files are unchanged.
• Cloud workspace: the control plane marks its product record archived. The current archive endpoint does not prune the AnyHarness worktree or its runtime history.

Archived workspaces are not available in a browsable archive screen in the current app. Cloud has a server restore operation, but Desktop does not expose that restore flow yet. Treat Archive as a one-way hide action in the current UI.

Pruning managed worktrees

Worktree retention is checkout cleanup. It is allowed to remove an old, Proliferate-managed worktree while preserving its runtime workspace and chat history. It never targets the primary local checkout you linked as a repo root.

Before a managed worktree can be removed, the runtime checks for blockers such as uncommitted changes, unresolved git state, live sessions or terminals, queued prompts, and running operations. Blocked worktrees are left alone.

Under Settings -> Pruning, Ideal worktrees sets the per-repository target used by the pressure indicator and retention policy. Automatic retention passes are off unless the runtime operator explicitly enables them. Changing the target does not make unsafe worktrees deletable.

The runtime pressure indicator and Details view show discovered Local and Cloud runtimes, their managed-worktree inventory, git status, and approximate checkout and history sizes.

Deleting runtime history

Delete workspace... on a Local worktree and Delete on an attached row in the Pruning inventory use the destructive AnyHarness purge path. After a confirmation and safety preflight, it removes:

• The managed checkout.
• The AnyHarness workspace record and sessions.
• Raw and normalized runtime events and transcript history.
• Runtime-local agent artifacts.

Git commits, branches, and pull requests remain. When the runtime workspace is attached to a Cloud workspace, the separate Cloud product record also remains; deleting runtime history is not the same as deleting that server record.

An orphaned worktree row has no attached runtime workspace. Deleting one removes only that clean, managed folder after its own safety checks.

Cloud sandbox lifecycle

Your cloud sandbox can pause when idle and wake on demand independently of any single workspace's archive or storage state. See Local & cloud.