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: a control-plane record for identity, lifecycle, routing, and read projections. Projections let product surfaces load session and transcript data without waking the sandbox. AnyHarness is still the source of runtime truth.

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

Creating a workspace

• 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 get the same chat, terminal, file, and review surfaces. Wake, isolation, authentication, and storage differ.

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

Archiving

Archive means "hide this from the UI". It does not delete anything or free disk.

• 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.

There is no archive screen to browse. Cloud has a server restore operation that Desktop does not expose yet, so treat Archive as one-way for now.

Pruning managed worktrees

Pruning is checkout cleanup. It removes an old managed worktree while keeping its runtime workspace and chat history, and never touches the local checkout you linked as a repo root.

Before removing one, the runtime checks for blockers: uncommitted changes, unresolved git state, live sessions or terminals, queued prompts, running operations. Blocked worktrees are left alone.

Under Settings → Pruning, Ideal worktrees sets the per-repository target the pressure indicator and retention policy use. Automatic retention is off unless an operator turns it on, and raising the target never makes an unsafe worktree deletable.

The Details view lists discovered runtimes, their worktrees, 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 survive. So does the Cloud product record, if there is one — deleting runtime history is not deleting that.

An orphaned worktree row has no runtime workspace behind it. Deleting one removes just that folder, after its own safety checks.

Cloud sandbox lifecycle

Your sandbox pauses when idle and wakes on demand, independent of any one workspace's archive or storage state. See Local & cloud.