Copilot CLI: New Conversation in a Worktree

To start a second Copilot CLI conversation in its own worktree while the first continues, leave the first session open and launch copilot --worktree from a second terminal. That creates a new worktree and starts a session inside it. If the first conversation is waiting for input, /worktree new is another option: it starts a new conversation in a new worktree while leaving the original conversation and working directory unchanged. A running local session remains active when you switch to another, as long as its CLI process stays open.

Start the second session from a terminal

Open another terminal at the repository you want to work on. For example, if the existing checkout is ~/src/shop, run:

cd ~/src/shop
copilot --worktree --name "cache fix"

The bare --worktree option asks Copilot CLI to generate a branch name. --name gives the conversation a name you can find later; it does not choose the Git branch name. You can now give this session a task while the first session stays open in its original terminal. Keep each terminal attached to its own session so you can respond to questions or permission requests from either one.

If you need a predictable branch name, supply one with an equals sign:

copilot --worktree=fix-cache --name "cache fix"

Copilot CLI can create or reuse the named worktree. If fix-cache already exists, this command may put the new conversation in that existing worktree. Use the bare option when the requirement is a fresh worktree, and use a name when you deliberately want that branch. The default location for CLI-created worktrees is under <repo>.worktrees/; check the actual path with git worktree list before opening files or running commands there.

Start from the checkout whose committed state should be the starting point for the second task. A worktree is a separate directory associated with the same repository, with its own checkout, HEAD, and index. Git supports multiple working trees for one repository, so each conversation can edit its own files without both agents writing to the same checkout. If the first task has made uncommitted edits, those edits do not appear merely because you create another worktree.

Use /worktree new inside Copilot CLI

When you can enter a command in an interactive session, /worktree new creates a fresh conversation and worktree together. You can include its first prompt, such as:

/worktree new Add tests for the cache invalidation path

Use this when you are already in Copilot CLI and want to start the second task there. To start immediately while the first conversation is processing a turn, the separate-terminal command above gives you an independent place to enter the next task. Copilot CLI’s sessions sidebar lets you switch among active local sessions: open it with ← from an empty prompt, select a session with ↑ or ↓, and press Enter. Its status indicators distinguish an agent processing a turn from one waiting for a permission decision or question.

Several similarly named commands do different jobs:

Command	Effect	Use it for
/worktree new [PROMPT]	Starts a new conversation in a new worktree; leaves the current conversation and directory unchanged.	A separate task from an interactive session.
/worktree [branch|task]	Creates a worktree and switches the current conversation into it, leaving uncommitted changes in the old directory.	Moving the current task to a separate checkout.
/move [branch|task]	Moves uncommitted changes into a new worktree and switches to it.	Relocating work already in progress.
/new [PROMPT]	Starts a new conversation.	Resetting conversation context when a separate worktree is not required.

The distinction matters when the first task must keep working in its existing directory. /worktree new addresses that case; /worktree changes the current conversation’s working directory. A new conversation alone does not provide a separate checkout. For more on what Git isolates, see Git worktrees explained.

Choose the starting commit deliberately

By default, Copilot CLI starts worktrees created by /worktree, /worktree new, and --worktree from the current checkout’s HEAD. Its worktreeBaseRef setting can instead use the remote default branch. If the second task should start from the latest commit on your current branch, the default is appropriate. If it should start independently from the remote default branch, set:

{
  "worktreeBaseRef": "defaultBranch"
}

Put that key in ~/.copilot/settings.json for a user-level default. The supported values are "head" and "defaultBranch"; "head" is the default. Review the setting before starting a task from a feature branch: branching from that branch’s HEAD includes its committed work in the new task’s starting point, which can complicate a later review against the default branch.

Neither base choice carries uncommitted changes from the first checkout. If the second agent needs those edits, decide which changes to commit and share first. /move can carry uncommitted changes into a new worktree, but it switches the current conversation, so it serves a different workflow from two independent tasks.

Find the work and keep the sessions distinct

Use git worktree list from any checkout of the repository to see each worktree’s path, current commit, and branch. This is more reliable than guessing a directory name, especially when Copilot generated the branch name. Give the agents clearly separate assignments—for example, one handles a cache bug while the other adds a test harness—and tell each which files or behavior it owns. Separate checkouts prevent simultaneous edits to the same working directory; they do not decide how overlapping changes should be combined later.

The sessions sidebar is useful for returning to a running conversation. If you close a local CLI process, its session becomes inactive rather than continuing to execute; you can reopen a saved session with /resume or start the CLI with copilot --resume. A named session can be selected with copilot --resume="cache fix". Do not combine --resume or --continue with --worktree: the worktree option is for starting a session and conflicts with those resume options.

Also consider resources outside the worktree. Two checkouts can still point at the same database, service, or port if the project’s configuration tells them to. Give parallel tasks distinct external resources when they run the application or tests concurrently; isolating test databases for parallel agents covers that situation.

Review and bring back the result

Find the second worktree with git worktree list, then inspect its files before integrating anything. For example, if the listed path is /src/shop.worktrees/fix-cache, git status --short shows tracked changes and untracked files:

git -C /src/shop.worktrees/fix-cache status --short
git -C /src/shop.worktrees/fix-cache diff

The second command shows unstaged changes in that checkout. Once the agent has committed its work, a three-dot git diff compares the branch against their merge base. For example, if main is the intended base and fix-cache is the branch:

git diff main...fix-cache

That branch comparison covers committed changes. Inspect uncommitted work separately with git status and git diff; otherwise it is easy to mistake an incomplete branch diff for the entire result. Inspect staged patch contents too:

git -C /src/shop.worktrees/fix-cache diff --cached

git status --short lists affected paths but does not display their patches. Untracked files require separate inspection because neither diff command displays their contents. Run the repository’s relevant tests in the second worktree, then review the patch and any conflicts with what the first agent produced.

After both tasks are ready, select the intended destination branch and commit or stash its outstanding changes before merging. Conflicts can make pre-existing uncommitted changes difficult to recover. Merge the finished branch into the currently checked-out branch, for example with git merge fix-cache. If the branches touch the same code, resolve the conflict and rerun the affected checks before treating the combined result as complete. The guide to merging parallel agent branches goes through that review in more detail.

When the second session is closed and its work is safely integrated or otherwise retained, remove its linked checkout with git worktree remove and the path shown by git worktree list. Git normally requires the worktree to be clean before removal. Use Git’s worktree command rather than deleting the directory by hand, so its worktree records are cleaned up too.

Where Parallel Code fits

Our product, Parallel Code, is a free, open-source desktop app for macOS and Linux that runs Copilot CLI and other AI coding agents in parallel, each in its own Git worktree. It launches the agent CLIs you already use locally and provides a diff-first review surface for comparing their changes.

Frequently asked questions

Can I use /new for the second task?

/new starts a new conversation, but it does not itself create a worktree. Use /worktree new or launch copilot --worktree when the task needs its own checkout as well as its own conversation.

Will the new worktree contain the first agent’s unfinished edits?

No. A new worktree starts from a commit, while uncommitted edits remain in the first checkout. Commit and share any work the second task depends on, or use /move if the real goal is to relocate the current conversation and its changes.

How do I find the branch and directory Copilot created?

Run git worktree list from the repository. It lists the linked checkout path and branch, including a generated name when you used bare --worktree.

Can I close the first session after starting the second?

Closing its CLI process stops that local session’s active work, although its saved conversation can be resumed later. Keep the process open if the first agent needs to continue while you work with the second.