[!NOTE] In Reliant, we call these Workspaces. Under the hood, they are standard Git worktrees.A workspace lives on the disk of one machine, the machine of the chat it was created for, and every chat that works in it runs there. That is also what a branched chat is: a chat whose workspace is its own branch on disk.
Creating a workspace
There are three ways to get one, and you will mostly use the first. Branch a chat into one. On any message, the branch menu offers Branch to New Workspace, which creates a workspace and opens a new chat in it with the conversation up to that message, or Branch to Existing Workspace, which puts the new chat in a workspace you already have. See Branching. Create one directly. Open the Workspaces panel (the workspaces button in the header, or Settings → Workspaces) and choose New workspace. Give it a name, and optionally a branch name (it defaults to the name) and a base branch (left blank, Reliant uses the repository’s default branch). In a project with several repositories you pick a base branch per repository. Bring in one that already exists. Import existing finds git worktrees already on the machine’s disk that Reliant didn’t make, and adds the ones you choose. Clone repository clones another repository onto the machine. If a branch or base name is wrong, for example a base branch that doesn’t exist, the workspace isn’t created and the dialog tells you what to fix.Working in a workspace
A chat runs in one workspace, and everything it does happens there: file reads and edits, shell commands, the Processes tab, and git. The Changes tab shows that workspace’s changes and is where you commit, push and open a pull request; see Git Integration. You can start several chats in the same workspace, each with its own history and the same files. A chat with no workspace runs on the project’s main checkout. Its Changes tab is read-only, so work you want to commit belongs in a workspace.The workspace page
Selecting a workspace in the Workspaces panel opens its page. The Working tree card shows uncommitted changes and how far the branch is from its upstream, Commits on this branch lists commits not yet on the base branch, Details shows the location on disk (with a copy button), the base branch and when it was created and last active, and Chats lists the chats working in it. The header holds the actions:
Archived workspaces are listed under the Archived tab of Settings → Workspaces, where Restore brings a workspace and its chats back.
Cleaning up
Worktrees take disk space, so archive a workspace when you are done with it and Reliant reclaims its directory without losing work. An archived workspace is removed from disk once nothing in it would be lost: it has no uncommitted changes and its branch is pushed or already merged, including by a squash or rebase merge. Commits that exist only in that workspace are saved in the repository before its directory is removed. One that still holds work Reliant can’t save that way, such as uncommitted changes, is kept, though rebuildable files likenode_modules and build output are deleted from it. Restoring a workspace whose directory was removed checks it out again.
When a machine’s disk runs low, the Inbox shows a storage item for it, and its Clean up action removes the archived worktrees you confirm.
Workspaces in workflows
A workflow can create workspaces itself with the Create Worktree node. It takes a name, an optional base branch and files to copy, and stores the new workspace’s path and branch for later steps. Workspaces a workflow creates appear in the Workspaces panel next to yours. The built-in Best of Three workflow (parallel-compete) works this way. It creates three workspaces from the same base branch, runs a separate agent with the same task in each, waits for all of them, and has a reviewer pick the winner or merge the best parts of each. Each agent has its own files and can install dependencies, build and commit without affecting the others.
Copying configuration files
Many projects have local files that aren’t committed but are needed to run, such as.env or .env.local. The Create Worktree node’s copy_files parameter copies them into the new workspace.
Each entry is an exact path from the workspace root, copied to the same place in the new workspace. Nothing is searched for: .env copies only the .env at the root, so a project with frontend/.env and backend/.env lists both paths. A directory is copied whole, which makes web/node_modules a valid entry, and a path that does not exist is skipped. In a multi-repo project, prefix the repo’s folder: api/.env.
Best practices
Use descriptive branch names that follow your team’s conventions, such asfeature/user-authentication or bugfix/login-redirect, so it is clear what each workspace contains. Create one workspace per feature or fix, and keep the main checkout clean for reference.
When designing a workflow that creates workspaces, list the files a working checkout needs in copy_files, and give each workspace a name that says which approach it holds, so comparing the results is easy.