跪拜 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 ↗