Overview

All the work you do in Proliferate happens in a workspace.

A workspace is an isolated environment tied to one repository, one branch, and one runtime. You pick where that runtime lives when you create the workspace: a local checkout, a new worktree, or the cloud.

You can see all your workspaces in the sidebar. The indicators show whether a workspace is a local checkout, worktree, or cloud workspace, and whether it was created by an automation or another agent.

What goes in a workspace?

In a single workspace you can have:

• Multiple chats or agent sessions.
• Multiple terminals.
• Multiple browser or preview surfaces, when the repo has a runnable app.
• Git review and status.
• File browsing.

Parallel agents

Parallel work is safest when each agent has an independent branch or task.

Good parallel work:

• Fix independent bugs.
• Add tests while another workspace implements a feature.
• Compare possible implementations.
• Review a diff while another agent continues implementation.

Risky parallel work:

• Multiple agents editing the same files.
• Broad refactors without a plan.
• Database migrations without coordination.
• Infrastructure or release work without explicit approval.

Terminals and browsers

Use the right sidebar to spin up terminals and browsers to verify the work being done.

Browsers and terminals run wherever the workspace runs: local checkout, worktree, or cloud workspace.

File browser

The file browser keeps the workspace grounded in the actual repository. Use it to move from an agent conversation into the files it created, edited, or referenced.

It is especially useful while work is still in progress:

• Inspect the repository tree without leaving the workspace.
• Open files mentioned in a chat, terminal, browser, or review.
• Check generated files, config changes, and test updates before approving the next step.
• Keep your place while switching between chats, terminals, browsers, and git review.

The file browser follows the selected workspace. If the workspace is local, it reads from your local checkout or worktree. If the workspace is cloud-backed, it reads from the remote environment attached to that workspace.

Git review

Git review is the checkpoint between "the agent changed code" and "this is ready to ship."

Use it to inspect the branch as a real diff, not just as a transcript summary. The review surface should be where you answer:

• What files changed?
• Is the diff focused on the task?
• Did the agent leave unrelated edits behind?
• Do tests, generated files, and configuration changes make sense together?
• Should this be revised, committed, opened as a PR, or marked done?

When something looks off, send the agent back into the same workspace with a specific follow-up. Keep the review tight: ask for a smaller diff, a missing test, a clearer implementation, or an explanation of one file before moving on.

Configuring workspaces

Each repository carries its own workspace configuration, and Local and Cloud keep separate copies of it. Open Settings → Repo to set:

• Configure: the default branch new workspaces for this repo branch from.
• Actions: a setup script that prepares a fresh checkout, and a run command that starts your app, service, or dev server.
• Environment: environment variables and files synced into cloud workspaces for this repo.

See Configuration for the full walkthrough, and Local & cloud for how cloud workspaces run.

Go deeper