跪拜 Guibai
← All articles
Frontend · Backend · Artificial Intelligence

Git Worktrees Are the Isolation Layer AI Coding Agents Need

By 阳光是sunny ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

AI coding agents that share a single working directory pollute each other's context and burn tokens on unrelated diffs. Worktrees give each agent a clean, isolated checkout, making parallel AI-driven tasks safe and reviewable without the overhead of full clones.

Summary

A single Git repository can spawn multiple linked working directories — each with its own HEAD, staging area, and working tree — that share the same object database. This eliminates the stash-and-switch dance when juggling a hotfix, a feature branch, and an AI agent's experimental refactor simultaneously.

Claude Code and similar tools now create a worktree per session by default, often tucked inside a hidden `.claude/worktrees/` folder. That default explains the common head-scratcher where edits seem to vanish: the dev server runs against the main tree while the AI silently modifies a detached worktree copy.

Worktrees also provide a cheap sandbox. An agent can trash its own directory without touching the main codebase; a bad experiment is a single `git worktree remove` away. Configuration files like `.env` don't carry over automatically, but a `.worktreeinclude` file can tell the tool which ignored files to replicate.

Takeaways
— Git worktree creates multiple working directories from one repository, each on its own branch, sharing the same object database and history.
— Claude Code automatically spawns a worktree per session inside `.claude/worktrees/`, which is why edits can appear to have no effect when the dev server runs from the main tree.
— A worktree can be created from an existing branch, from a new branch off main, or as a detached HEAD for throwaway experiments.
— Deleting a worktree is a single command; if the directory was removed manually, `git worktree prune` cleans up the stale metadata.
— Git refuses to check out the same branch in two worktrees simultaneously to prevent conflicts.
— Configuration files ignored by Git (like `.env`) won't appear in a new worktree unless a `.worktreeinclude` file explicitly lists them for the tool to copy.
— Adding `.claude/worktrees/` to `.gitignore` keeps auto-generated worktrees out of the main repo's untracked files.
Conclusions

Worktrees turn branch isolation into a filesystem-level concern, which maps cleanly onto how AI agents already operate — one session, one directory.

The confusion over "missing edits" is a UX failure, not a Git failure: tools that silently redirect file writes to a hidden worktree break the user's mental model of where code lives.

Worktrees are lighter than clones but heavier than `git stash`; the trade-off pays off only when you genuinely need concurrent, long-running work on different branches.

AI tooling is pushing a 2015-era Git feature into the spotlight because the old assumption — one developer, one working tree at a time — no longer holds when multiple agents act on the same repo.

The `.worktreeinclude` pattern is a pragmatic stopgap, but it highlights a missing primitive: worktrees don't have a standard way to declare which untracked files should follow a branch.

Concepts & terms
Git worktree
A linked working directory attached to a single Git repository. Each worktree has its own checked-out branch, HEAD, and staging area, but shares the underlying object database and history with the main repository.
Detached HEAD worktree
A worktree created without associating it with a branch, pointing directly to a specific commit. Useful for quick experiments or build tests that should not create permanent branch references.
.worktreeinclude
A project-root configuration file that tells Claude Code which normally-ignored files (like `.env`) to copy into a newly created worktree, since Git's own ignore rules would otherwise exclude them.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗