Worktree Isolation and Conversation Context Solve Different Problems

Check two mappings before asking an agent to edit code: which working tree it can change, and which task instructions its conversation is following. A separate directory helps organize code work; it does not establish what an agent remembers or which instruction it will treat as current.

You can inspect both mappings with a small task card. This matters whenever two tasks look similar enough that a directory name or a familiar chat title could give false confidence.

Separate the objects

Git's worktree manual describes multiple working trees attached to one repository, with per-worktree state such as HEAD and the index while repository resources remain shared. That is code-management behavior. Git does not define an agent host's conversation history, context selection or permissions.

Keep the distinction explicit:

Layer	Object to identify	What to inspect
Task	The result you want	Current goal, allowed change and next action
Code	Working directory and checked-out state	Worktree root, branch or detached state, revision and existing changes
Conversation	The instructions and references being used	Current request, recent decisions and the actual artifacts cited
Host behavior	How the agent tool connects conversation and workspace	The selected tool's current documentation and visible configuration

A linked worktree is not a security sandbox. A conversation title is not proof that the next tool action will target the right directory.

Map two fictional tasks

The following example is illustrative. It does not describe live worktrees or chats.

Task	Intended working tree	Intended branch	Conversation
F: article filtering	`/example/worktrees/filter`	`feature/filter`	`Filter behavior`
E: export formatting	`/example/worktrees/export`	`feature/export`	`Export columns`

flowchart LR
    TF["Task F · Filtering"] --> WF["Worktree filter · feature/filter"]
    TF --> CF["Conversation · Filter behavior"]
    TE["Task E · Export formatting"] --> WE["Worktree export · feature/export"]
    TE --> CE["Conversation · Export columns"]

The code and conversation arrows must both match the intended task. A correct arrow on one side cannot compensate for a wrong arrow on the other.

Check the four combinations

Code destination	Conversation context	Example	Next action
Correct	Correct	Filter directory and current filter request agree	Continue with the scoped task
Correct	Wrong	Filter directory is open, but the request still describes export columns	Restate the current filter task and confirm the references before editing
Wrong	Correct	Filter request is clear, but the available workspace is the export worktree	Select or arrange the correct workspace before a code change
Wrong	Wrong	Export directory and old export instructions are being used for the filter goal	Re-establish both mappings from the original task and artifacts

This table describes checks you can perform. It does not diagnose a host bug or promise recovery of missing chat history.

Inspect the Git side without changing it

From the terminal or execution environment that will perform the task, these inspection commands identify the working tree and revision:

git --version
git rev-parse --show-toplevel
git rev-parse --abbrev-ref HEAD
git rev-parse HEAD
git worktree list --porcelain

Read the rev-parse options alongside the worktree listing. --show-toplevel identifies the worktree root. An abbreviated HEAD value should not be treated as a branch name when the checkout is detached; record that state and its revision explicitly.

Run these in the environment the agent will actually use. Checking another terminal's directory does not establish the agent's execution directory. The commands here are inspection steps; creating, switching, resetting or deleting a worktree is a different action.

Copy the two-layer task card

Task:
Current requested result:
Allowed change:

Code mapping:
- Observed worktree root:
- Branch, or detached state:
- Revision:
- Existing local changes and their owner:

Conversation mapping:
- Conversation title/reference:
- Latest applicable request:
- Decisions to retain:
- Current artifact references:

Agreement check:
Do the request, paths and artifacts all belong to this task?

Next action:

Record what you observe rather than filling the code fields from what the chat says should be open.

A complete manual check

For fictional Task F, imagine the directory inspection points to /example/worktrees/filter and the intended branch. The latest conversation message, however, says: “Rename the export columns and keep their order.”

The code mapping fits F; the conversation mapping does not. A useful correction is:

Current task: article filtering.
Code destination: /example/worktrees/filter, feature/filter.
Retain the filter contract: empty query returns all permitted items,
and matching preserves item order.
The export-column request belongs to the separate export task.
Before editing, identify the filter implementation and relevant checks
in this worktree, then state the next proposed change.

Those paths and statements are fictional inputs, not captured command output. In real work, first inspect any existing changes and preserve their ownership; do not erase them to make the workspace resemble the task card.

Check host-specific behavior separately

Git question	Agent-host question
Which files and revision are checked out?	What workspace is this conversation allowed to access?
Which branch does this worktree use?	Which instructions and notes are supplied to the agent?
What state is shared through the repository?	What context is retained, summarized or shared between tasks?

Answer the right-hand questions from the selected host's current behavior and documentation. Do not transfer a feature from one agent product to another by analogy. If either mapping is unclear, resolve that uncertainty before making the code change; the mapping card remains useful even when no special multi-agent interface is involved.