Vortex logo vortex Download

Work on separate changes

4 minute read · Projects & Git

Use separate conversations for changes that need their own context. They can share a branch, or you can give one an isolated worktree so the file edits stay separate.

Decide whether chats should share files

Two chats on the same branch can work on independent parts of an app. They still edit the same checkout, so simultaneous changes to the same file can conflict. Tell each chat its exact responsibility, such as article-list styling versus API validation, and review the combined result before committing.

Choose a worktree when you need an isolated branch and directory for a task. The worktree is derived from the parent project, with its own branch and directory. It may still need its own dependency preparation, running processes or port configuration. A second checkout is not a second database unless you explicitly configure one.

Choose where this chat works

  1. Open the chat's menu and choose Project & worktree….
  2. Select the project in the workspace. This is the starting project for the next message; the agent can still use other included projects when the task calls for them.
  3. Under Working copy, choose Main folder to use its existing checkout, or choose an existing branch with the fork icon to use that worktree.
  4. To isolate new work, choose New worktree, enter the branch and base branch, then use Create & use worktree. Check the resulting branch and folder before asking the agent to edit there.

The chat retains its messages and draft when you choose a working copy. Each project can have its own working-copy choice in that conversation. Changes are unavailable while the chat is running, finishing work or has queued messages; let it finish before switching.

Normal main-folder chats keep their sidebar entries and composer footers compact, without a repeated project/branch line. An isolated chat shows a fork icon and its branch context, including beneath the composer. Open that compact indicator to return to the same chooser. Its colour follows the selected palette and theme, and the provider logo remains beside the chat title.

Files and Source Control badges are for browsing. Choosing another project or worktree there does not reassign this chat or change an agent's current working directory. The Project & worktree… chooser changes the chat's starting context and brings its working copy into view. See project badges and panel sizes.

Saved connections and Git history remain shared with the parent project. A database is not copied. Prepare dependencies, environment variables, services and ports for each working folder as needed, and configure its Preview separately. Existing terminal sessions keep their folders; new project terminals use the selected checkout.

Finish an isolated change

  1. Open the task's worktree and confirm its current branch and changed files.
  2. Run the relevant project checks there and inspect the actual result.
  3. Open Project & worktree… → Review & merge for the selected worktree. Inspect the source, target and review before confirming the merge when the source and destination states permit it.
  4. If a merge conflicts, inspect and resolve the affected files, then rerun the checks that cover the resolution.
  5. Verify the parent checkout before removing an unused worktree through its explicit action.

Do not delete a project directory to close a worktree tab. Closing a UI surface, archiving a chat and removing a checkout are different operations.

After a worktree is merged or removed, it leaves the active badges in Files and Source Control. The chat's Merge history keeps the recorded branch, target and commit information. A successful merge does not itself authorize a push or deployment.

Coordinate commits and running apps

A manual commit records the selected current changes; it is separate from agent automatic-commit safeguards. If two chats share a checkout, review whether the commit includes both tasks. Switching branches, pulling or finishing a worktree while an app or agent is using the files can change its working context. Follow the busy/dirty checks and avoid treating a disabled control as a reason to run an equivalent destructive shell command.

Test the parts together

Suppose one chat updates the API response and another adds a search interface. Give each chat the expected request and response shape, then test the combined flow in the preview: enter a search, inspect the request, compare the response and verify the displayed rows. Passing each task's own check is useful, but it does not establish that the two changes agree.

Keep database configuration explicit in isolated worktrees. Two checkouts can still point to one database, share an upload directory or compete for a port. Review the project's environment and startup commands before running them side by side. Changing one worktree's branch does not isolate external services automatically.

When only a linked task's result remains, use the local wait/resume workflow instead of repeatedly asking for its status. The linked chat retains its approvals and exact run result. Review a failure or partially completed merge with its evidence; do not discard a checkout to make the task appear finished. Read linked tasks and Git review before combining independent work.

Updated Sep 22, 2026 · Need a hand?