Lifecycle + Monitoring
Understand how workspaces start, run, get reviewed, and get cleaned up.
A workspace moves through a simple lifecycle: create, set up, run, review, and wrap up.
Proliferate keeps the work attached to the repository and branch so you can return to it later, inspect what happened, and decide what should ship.
Workspace lifecycle
| Stage | What happens |
|---|---|
| Create | Proliferate attaches the repo, branch, scripts, and agent context, then creates the checkout or cloud sandbox. |
| Set up | The setup script runs once against the new worktree or cloud sandbox. |
| Run | Agents use the workspace to plan, edit, test, and explain their changes. |
| Review | You inspect files, diffs, command output, and pull request state. |
| Wrap up | Publish the branch, then archive or delete the workspace. |
Workspace status banner
Banner above the composer showing setup progress ('Creating worktree...', 'Provisioning cloud workspace...') or a persistent setup-failure state with the failed command, exit summary, and a link to the terminal output.
Cloud workspaces show their own provisioning steps while the sandbox comes up: Queued, then Preparing runtime, then Ready. If you've saved a setup script or environment files for the repo, a short Applying tracked files or Starting cloud setup step follows before the workspace is usable. If provisioning fails, the workspace stays around with a retry action; if cloud usage is paused or a concurrency limit is hit, the same screen explains why and what to do about it.
Monitor agent work
Everything below lives in the workspace itself, in the right-hand panel next to the chat.
- Transcript: the streaming chat with the agent, including plans, tool calls, and subagent activity.
- Terminal: real shell access inside the workspace, for commands the agent runs and ones you run yourself.
- Browser preview: a live view of the app when the repo has one running.
- Files and git diffs: browse changed files, and review unstaged, staged, or "last turn" diffs in unified or split layout.
- Pull request status: once a branch has a PR, its state shows next to the workspace.
Workspace right panel
Tabbed right panel next to the chat with Terminal, Browser, Files, and git review tabs open on a workspace, each tab showing its own header controls.
The git panel is also where you act on changes, not just look at them: stage or unstage individual files, switch the diff base, and undo the last agent turn's file changes as a single operation if it went the wrong way.
Git review panel
Diff review panel with an Unstaged/Staged/Last turn filter, unified/split layout toggle, per-file stage and undo controls, and an aggregate additions/deletions count in the header.
Pull request state shows up as a small badge next to the workspace name in the sidebar: Open, Draft, Merged, or Closed, plus a warning tone when checks are failing or pending, or when changes have been requested. Ahead/behind counts show when the branch has diverged from its base.
Sidebar pull request badge
Sidebar workspace row with a PR glyph and tooltip reading something like 'PR #805 · Open · Checks failing', next to ahead/behind arrows.
Use monitoring to decide whether to let the agent continue, redirect it, or move into review.
Publish and review
When a workspace's changes are ready to leave the workspace, use Publish to push the branch, and optionally open a pull request in the same step.
Publish dialog
Publish dialog with a changed-files summary, a pull request title and description form, and Publish branch / Publish pull request actions.
Publishing pushes real commits to your remote. Review the diff in the git panel first, especially for cloud workspaces you haven't been watching closely.
Wrap up work
Two workspace actions close out finished work, both from the sidebar's workspace menu:
- Archive: hides the workspace from your active list without touching its history. Unarchive brings it right back.
- Delete: removes the local worktree, workspace record, chat history, and local agent artifacts. Commits, branches, and pull requests are not deleted, since those live in git and on GitHub. This can't be undone from Proliferate.
If you're not sure which one you want, archive first. You can always delete later.
Keep storage under control
Worktrees accumulate on disk as you create more workspaces. Settings → Pruning lets you set an ideal number of worktrees per repo; once you're over that, the composer shows a pressure indicator, and cleanup can reclaim space from workspaces that are clean and not in active use. Dirty checkouts (uncommitted changes, live sessions, running commands) are always skipped.
Settings: Pruning
Settings → Pruning showing the 'Ideal worktrees' per-repo stepper and a per-runtime status row with a pressure ring, usage label, and a Details button.