Two AI coding agents should not make unrelated edits in the same working directory at the same time. Their changes can overlap, overwrite one another, or make it hard to tell which task produced a failing test. Git worktrees give separate tasks their own directories while keeping them linked to one repository.
Understand what a worktree changes
A Git worktree is another checked out working directory attached to the same repository. Each worktree has its own branch and files, while the repository shares Git objects and references. You can work on a feature in one directory while a second task proceeds in another.
A worktree isolates the checked out files. It does not guarantee that two tasks have no conceptual overlap. Both agents may edit the same shared API in separate branches, and those changes still need to be reconciled when you combine them. Give each task a distinct responsibility and tell the agents which files or behavior are shared.
Create one branch and directory per task
Begin from a clean, understood repository state. Use a descriptive branch name and a directory outside the current checkout. The example creates a separate branch for a sample task. Replace the names with your own and confirm the branch is not already checked out elsewhere.
A prompt to adapt
git worktree add ../agent-auth -b agent/auth-feature
git worktree listChoose tasks that can actually run side by side
Parallel work is useful when tasks have separate outcomes, such as writing documentation in one worktree while a person fixes a contained bug in another. It is less useful when both tasks need to change the same shared component, migration, API contract, or lockfile. In those cases, work in sequence or define which task owns the shared files.
Give each agent its own repository path, branch name, instructions, and acceptance criteria. Ask it to report the starting commit and changed files. Do not let one task merge another branch or change the shared working directory without a person coordinating the integration.
| Good to separate | Coordinate first |
|---|---|
| Documentation and an isolated bug fix | Two edits to the same component |
| Independent packages with clear ownership | A shared API and its dependent implementation |
| A test only task and a separate design task | Two dependency updates that change one lockfile |
Review before you combine the branches
Check each worktree’s branch, status, and diff. Run the checks that match the files changed. When you merge or rebase a completed branch, inspect the combined diff and rerun the affected tests. A clean merge only means Git applied the edits; it does not prove that the combined behavior is correct.
When a worktree is no longer needed, save or commit any changes you want to keep before removing it. Git normally refuses to remove a worktree with uncommitted changes. Avoid force removal unless you have verified that no needed work is inside it.
- Give each task a separate branch and working directory.
- Tell each agent its scope and the shared files to leave alone.
- Review each diff and run its focused checks.
- Integrate deliberately, then test the combined result.
Use parallel work only when it saves coordination time
A second agent adds setup, review, and merge work. Start one task in a separate worktree and see whether it finishes independently before scaling up. Git’s worktree commands are documented by the Git project. LucentraCode users can run each CLI task from its own project directory and inspect its resulting branch with the same Git workflow.