Understand when to use Solo
Choose Solo when work needs its own branch and working folder.
Last updated 16 September 2026
Choose Solo when work needs its own branch and working folder.
Before you start
Use a Git project and choose a task with a clear boundary. Consider how the result will eventually be reviewed and brought back.
The Solo scope has its own file changes, separate from the main project’s Git view.
Step by step
Use a normal agent for work that should share the current project files with other activity.
Choose Solo for an independent change, experiment, or parallel task whose edits should remain in a separate working folder.
Before starting, check the source branch. Solo begins from its selected Git base; do not assume unrelated uncommitted main-project edits are included.
After the task starts, use the Solo badge and branch strip to identify its scope. Inspect its files through the Solo Git view.
Review and test the result in that scope, then use Rejoin when you want to merge it into a local target branch. Use the separate Ship flow when delivering a branch remotely.
What to expect
You have chosen a workspace boundary that keeps parallel file changes understandable.
Troubleshooting and useful details
The screenshot shows one added file in a Solo Git view. A separate working folder is not a security sandbox: agents can still have configured tool or network access. Services, databases, and external accounts can remain shared even when source files are isolated.
