Why coding agents should work on a copy of your repo

A coding agent should work on its own copy of your repository, on its own branch, so that nothing it does touches your working files until you have read the diff and merged it yourself. Git worktrees are the simplest way to do this: one repository, several separate working directories, each on a different branch.

This guide explains what goes wrong without isolation, how worktrees work, the commands you need and the limits you should know about.

What goes wrong in a shared directory

If an agent edits the same directory you are working in, several problems appear quickly.

• Mixed changes. Your half-finished work and the agent's edits end up in the same set of uncommitted changes. Telling them apart later is tedious and easy to get wrong.
• Moving ground. The agent changes a file while you are reading or editing it. Your editor, your running development server and your tests all see a project that keeps shifting.
• Harder review. There is no clean line between before and after, so there is no single diff that shows what the agent did.
• Harder undo. If the result is poor, you want to throw it away. In a shared directory, discarding the agent's changes risks discarding your own.
• Collisions between agents. Two agents in one directory overwrite each other's files and run tests against each other's unfinished work. See running more than one AI coding agent.

Isolation solves all five with one idea. The agent's work lives somewhere else until you choose to bring it in.

What a git worktree is

Normally a git repository has one working directory: the folder where the files of your current branch are checked out. A worktree is an additional working directory attached to the same repository. Each worktree has its own checked-out branch, its own files on disk and its own staging area. All of them share one underlying store of commits and history.

That sharing is the advantage over making a second clone. There is no second copy of the history to download or keep in step. A commit made in one worktree is visible from the others straight away, because there is only one repository underneath. You can compare, cherry-pick or merge between them without pushing or pulling anything.

Git applies one rule that helps here: the same branch cannot be checked out in two worktrees at once. Each agent is therefore on its own branch by construction.

The basic commands

Create a worktree in a sibling folder, on a new branch:

git worktree add ../myproject-fix-login -b agent/fix-login

See what exists:

git worktree list

Review the work from your main directory when the agent has finished:

git diff main...agent/fix-login

Merge if you are satisfied, then tidy up:

git merge agent/fix-login
git worktree remove ../myproject-fix-login
git branch -d agent/fix-login

If a worktree folder was deleted by hand, git worktree prune clears the leftover record.

Many agent tools now create and remove worktrees for you. It is still worth knowing what happens underneath, because at some point you will need to find a branch or clean up after a session that ended badly.

A simple workflow

1. Create a worktree and branch for the task. Name the branch after the task, and the agent if you use several.
2. Start the agent in that directory with a bounded task and a clear finishing condition, such as a test that must pass.
3. Let it work freely there. Because nothing counts until you merge, the agent does not need to ask before each edit. This removes most of the small permission prompts that people learn to click through, a problem described in designing approvals people do not skip.
4. Review one diff. Read it as you would a colleague's pull request. Run the checks.
5. Merge it yourself, ask for changes, or delete the branch and lose nothing.

The important shift is that review happens once, at a natural boundary, with the full change in front of you.

Things that catch people out

Files git does not track are not copied. A new worktree contains only tracked files. Installed dependencies, build output and local settings files that git ignores will be missing. You will usually need to run your install step in each worktree, and provide any local configuration the project needs. Be careful about copying secrets into a directory an agent can read; give it test credentials where possible.

Disk space and install time. History is shared, but each worktree has its own checked-out files and its own installed dependencies. For large projects this adds up. Remove worktrees when you have finished with them.

Shared machine resources. Separate directories do not give you separate ports, databases or caches. Two worktrees running the same development server will collide on the port. Give each its own, or run one at a time.

Stale branches. If the main branch moves on while an agent works, its branch falls behind. Bring it up to date before you review, so you are judging the change against the current code.

Submodules and unusual setups. Projects that use git submodules or depend on absolute paths may need extra care. Test the process once by hand before relying on it.

A worktree is not a sandbox

This point matters most. A worktree isolates the agent's changes from your working files. It does not restrict what the agent can do on your computer. An agent that can run shell commands can still read other folders, use the network and reach anything your user account can reach. It also shares the repository's configuration and hooks with your main checkout.

For protection against a misbehaving agent or a malicious instruction hidden in something it reads, you need other measures as well: limited tools and permissions, approval for risky commands, and for stronger separation a container or virtual machine. See skills, plugins and tool servers explained for how an agent's reach is decided. Use worktrees to keep work organised and reviewable, and use permissions and sandboxes for safety.

Equally, keep the step that leaves your machine under your own control. An agent can commit to its branch as often as it likes. Pushing to a shared remote, opening a pull request and merging are better kept as decisions a person makes.

Where Prism fits

In Prism Desktop, agent coding sessions run on an isolated copy of the repo. You review the diff, and you merge. A terminal is available locally or over SSH, and the AI vendors' own agent programs run side by side. A merge is one of the decisions a person approves, and decisions are recorded. Early access is by waitlist: join the waitlist.