Git worktrees give parallel coding Agents separate checked-out files and branches while sharing a repository's object database. They help prevent accidental edits to the same working files. They do not create a security sandbox or automatically isolate ports, databases, credentials, and external accounts.
Use this guide for a local Git checkout you control. It is not a claim that Agent.Space automatically provisions one worktree per Agent. The Git commands follow the official worktree documentation, checked September 29, 2026.
Decide what should be isolated
Give each concurrent editing task its own directory and branch. A read-only review may not need another worktree, but it should still identify the exact revision being reviewed.
Split tasks by independent change boundaries. Two Agents changing the same schema will still need coordination even if their files are physically separate. Use the multi-agent coding workflow to decide whether parallel work is useful before adding directories.
Create worktrees from an explicit baseline
First inspect the existing checkout:
Do not move or discard uncommitted work. For this example, suppose main is your intentionally chosen local baseline, the branch names are unused, and the sibling paths do not already exist:
These commands create local branches and directories; they do not publish them. Start each Agent in its assigned path. Ask it to confirm the path and branch before editing:
Choose names and a baseline appropriate to your repository. A local main may be behind the remote; deliberately update or select your baseline before starting, rather than assuming the name means “latest.”
Keep shared resources from colliding
Worktrees share Git metadata and can still access other paths if the process has permission. For untrusted code, use an appropriate execution sandbox and credential boundary; worktrees alone are insufficient.
Review the combined result
Have each Agent provide its diff, tests, and unresolved assumptions. Commit only the intended changes according to the repository's workflow.
Integrate through the normal reviewed process. Resolve conflicts explicitly and run relevant checks on the combined revision. Even changes that merge without a textual conflict can disagree about behavior.
The coding Agent handoff guide provides a useful record for this stage. Do not let one Agent silently overwrite another's work to make a test pass.
Remove only work you have preserved
Stop processes using the directory. Confirm the work has been committed and retained where required, then inspect its status before removal:
If Git refuses because the worktree is dirty, inspect the files rather than using force. Removing a worktree directory and deleting its branch are separate decisions. Keep the branch if it remains part of review or recovery.
For a hosted project workflow, see how Agent.Space works. Open Agent.Space if that environment fits your task, while keeping concurrency, ownership, and approval rules explicit.