Git worktrees for AI coding agents: a safe workflow.
A Git worktree gives another task its own checked-out folder and branch while sharing the same repository history. That makes it useful for running several coding-agent attempts without making them edit one working tree.
The short answer
Give every AI coding agent one linked worktree, one branch and one narrowly defined task. Create the worktree from a known base, start the agent inside that folder and keep the primary checkout for review. When an attempt finishes, inspect its status, diff and commits before merging anything. Compare parallel attempts from the common base, choose one result, run the repository's tests and merge through your normal review path. Remove a worktree only after its useful changes are committed or deliberately discarded. Worktrees reduce file collisions because agents write in separate directories, but they are not security sandboxes: linked worktrees share the repository object database and refs, and an agent with broad shell access can still run destructive Git or filesystem commands. Use host permissions and an approval boundary for writes that require human control. This workflow works with Codex, Claude Code, Cursor and other tools that can operate inside a chosen directory.
1. Create one branch and worktree per agent task
# Run from the primary checkout.
git fetch origin
git worktree add -b agent/search-fix-a ../project-search-a origin/main
git worktree add -b agent/search-fix-b ../project-search-b origin/main
# Confirm the folders, branches and current commits.
git worktree listStart each agent with its working directory set to the matching folder. Keep task A out of task B's folder and avoid checking the same branch out in two linked worktrees.
2. Give each attempt the same acceptance criteria
Parallel agents are useful only when the comparison is fair. Give both the same base commit, task statement, tests and constraints. Ask them to commit their result on their own branch. A worktree separates files; it does not prevent an agent from changing unrelated files, rewriting its branch or reaching shared remotes if its permissions allow that.
3. Compare the attempts before merging
# Inspect each branch from the primary checkout.
git status --short
git log --oneline origin/main..agent/search-fix-a
git diff --stat origin/main...agent/search-fix-a
git diff origin/main...agent/search-fix-a
git log --oneline origin/main..agent/search-fix-b
git diff --stat origin/main...agent/search-fix-bReview behavior, tests and scope. Do not merge both attempts merely because both completed. If useful ideas are split between branches, cherry-pick a verified commit or ask for a clean combined change on a new branch.
4. Merge the chosen branch through the normal gate
git switch main
git pull --ff-only
git merge --no-ff agent/search-fix-a
# Run the repository's own tests before pushing.A worktree changes where the code is checked out; it does not replace code review, CI, branch protection or human approval. If the agent can push directly, the worktree alone does not stop it.
5. Clean up only after review
# Ensure the worktree has no work you intend to keep.
git -C ../project-search-a status --short
git worktree remove ../project-search-a
git branch -d agent/search-fix-a
# Prune stale administrative entries if a folder was removed manually.
git worktree prune --dry-runRun git worktree prune without --dry-run only after reviewing what Git considers stale. The official Git worktree documentation covers locking, moving, repairing and pruning linked worktrees.
What worktrees isolate, and what they share
| Separated per worktree | Shared or still reachable |
|---|---|
| Checked-out files and working-tree changes | Repository objects and most refs |
| Current branch and per-worktree state | Remotes and network credentials |
| Task folder and local build artifacts | Anything a broadly permitted shell can access outside that folder |
Use worktrees for parallelism and cleaner comparison. Use permissions, protected branches, review and approval controls for authority.
See parallel attempts, compare them and guard the merge.
FluxGit surfaces linked worktrees in the desktop app, can compare parallel attempts and routes supported agent Git writes through proposal and approval. A separate shell granted by an agent host remains outside that boundary.