What Git Worktrees Still Share Between Coding Agents

Quick answer: Linked worktrees give agents separate working directories and indexes while retaining shared repository state. Inventory shared refs, stash, configuration, hooks, and host resources. Assign ownership for each mutation and identify results by immutable revisions before integrating them.

Two agents can work in different directories, on different branches, and still interfere through Git. The directories tell you where edits land. They do not describe every piece of state a command can change.

This is a consequence of Git's documented worktree design. Understanding that design lets you choose useful boundaries and avoid relying on isolation you have not established.

The examples below describe hypothetical workers A and B. No repository was created or modified to execute them.

Inventory the shared repository

Git's repository layout distinguishes common storage from worktree-specific state. Objects and ordinary branch refs belong to the shared repository; a linked worktree has its own index and HEAD. The repository layout manual explains how common and private paths are resolved.

Start with a working inventory:

Resource	Relationship between linked worktrees	Coordination question
Checked-out files	Separate working directories	Who may edit this directory?
Index and HEAD	Specific to each worktree	Which worker stages and commits here?
Objects and ordinary branch refs	Shared repository storage	Who may change a shared branch?
Stash	Shared refs/stash history	Who owns each saved state?
Repository configuration	Shared unless configured otherwise	Who may alter repository behavior?
Hooks	Determined by effective configuration and paths	Which code runs for this worker?
Ports, credentials, caches, external services	Determined by the host and application	What additional isolation is required?

The last row needs its own investigation. Git does not allocate private server ports or database accounts when you create a worktree. Decide whether concurrent workers can safely use the same services, and give each one a separate resource where the task requires it.

Treat stash as shared state

Git records the newest stash at refs/stash, with older entries reachable through its reflog. The stash manual documents that storage. Combined with Git's shared-ref rules, this means linked worktrees share the stash stack.

Consider this illustrative sequence:

1. Worker A saves unfinished edits as a stash.
2. Worker B saves its own unfinished edits.
3. Worker A later asks to restore the newest stash without identifying it.

The newest entry now belongs to B. A's current directory does not make its earlier entry the top of the stack again.

If a workflow must use stash, capture the exact object identity, associate it with its owner and base revision, and prefer applying that identified state before deciding what to delete. Git permits stash apply to use a suitable stash commit directly; successful pop also removes the selected entry. Neither operation makes the storage private.

For routine agent handoffs, a checkpoint commit on an owned branch or an explicitly named patch artifact is often easier to reconcile. Record what the checkpoint includes and keep the branch or artifact available until the work is accepted. An unreferenced object identifier is not a retention policy.

Give shared mutations one owner

Most refs under refs/ are shared, with documented exceptions such as refs/bisect, refs/worktree, and refs/rewritten. Worktree-specific HEAD does not make the branch it names a private repository. See Git's worktree ref rules.

For a small parallel task, assign one owner to each worker branch and one integrator to the destination branch. Require an explicit handoff before another worker changes those refs. Apply the same policy to shared recovery state: deleting stash entries, rewriting history, and changing repository-wide settings need an identified owner.

That policy can be lightweight. A task record might say:

Worker A: installation guide; branch task/install
Worker B: command reference; branch task/commands
Integrator: destination branch and shared repository maintenance
Shared stash: not used for automatic handoff
Recovery: inspect and preserve owned changes before destructive actions

These are proposed coordination rules. They are useful only if the tool permissions and coordinator actually enforce the boundaries that matter. Instructions alone do not prevent a process with broad filesystem access from entering another worktree.

Check effective configuration and hooks

Git supports worktree-specific configuration through extensions.worktreeConfig and git config --worktree. Enabling that capability is a repository change with compatibility and configuration-migration considerations; consult the Git configuration documentation before adopting it.

For an audit, inspect values and their origins rather than inferring behavior from a directory name. An illustrative read-only query is:

git -C /path/to/worker-a config --show-origin --get core.hooksPath

An absent value means the setting is not explicitly resolved by that query; it does not prove there are no hooks. Git has a default hooks location. Its hooks documentation also explains that core.hooksPath can replace that location and that execution context depends on the hook.

Record which hook scripts can run for a worker and what they touch. A hook that writes to a common report file can create a coordination problem even when the commit's index is private. Review configuration changes as changes to execution behavior, rather than housekeeping.

Record where the worker actually operates

Before allowing writes, establish the actual checkout, repository, and revision. These illustrative commands inspect the supplied path:

git -C /path/to/worker-a rev-parse --show-toplevel
git -C /path/to/worker-a rev-parse --absolute-git-dir
git -C /path/to/worker-a rev-parse --git-common-dir
git -C /path/to/worker-a rev-parse --verify HEAD

The revision parsing manual documents these outputs. Resolve any relative path against the appropriate command context before comparing records. Record the base revision before editing and the candidate revision at handoff, along with relevant uncommitted changes.

If a worker changes directories or launches another process, preserve that identity deliberately. A correct initial assignment does not establish where every later command ran.

At integration, associate checks with the actual candidate being considered. A branch label can move, and a worker's tested commit may differ from the integrated result. Use the evidence approach in verifying the exact code an agent will ship.

Review recovery before it becomes urgent

Write down the allowed recovery steps while both workers are healthy:

• Preserve the relevant dirty changes and identify their owner.
• Inspect the exact branch, stash object, or artifact being recovered.
• Coordinate mutations of shared refs and configuration.
• Keep accepted work reachable until integration is confirmed.
• Read back outcomes after interruption before repeating a mutation.
• Report uncertainty when ownership or execution history is missing.

The stopped-agent recovery guide explains why an interrupted command needs read-back before retry. Apply that discipline to Git recovery as well.

Worktrees are useful when the task needs separate checkouts with shared history. Make the sharing explicit in the assignment. A directory, branch owner, revision record, and short shared-resource policy give the coordinator enough information to integrate work without guessing which state belongs to whom.