DEV Community: Aditya Goyal

Why coding agents should work on a copy of your repo

Aditya Goyal — Wed, 30 Sep 2026 01:53:19 +0000

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

Create a worktree and branch for the task. Name the branch after the task, and the agent if you use several.
Start the agent in that directory with a bounded task and a clear finishing condition, such as a test that must pass.
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.
Review one diff. Read it as you would a colleague's pull request. Run the checks.
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.

Written by Aditya Goyal, AI-assisted. First published at prismlabs.solutions.

What actually gets sent to an AI provider when you ask?

Aditya Goyal — Wed, 30 Sep 2026 01:52:48 +0000

When you ask an AI model a question, the provider receives the whole request, not only the sentence you typed: hidden instructions, the earlier conversation, any attached files or retrieved passages, and descriptions of the tools the model may use. The model has no memory between requests, so everything it needs to know must be sent again each time.

That second point surprises people. It is the key to understanding what leaves your device.

Models are stateless

A large language model, as served over an API, does not remember your last message. Each request stands alone. The appearance of memory in a chat comes from the application, which resends the conversation so far along with your new message.

So by the tenth message in a long chat, the request contains messages one to nine as well. If you pasted a long document in message two, that document is sent again with every later message in that conversation, unless the application trims or summarises the history. Some providers offer caching so that repeated content is cheaper and faster to process, but the content is still part of the request.

The parts of a typical request

Part	What it is	Who wrote it
System prompt	Standing instructions: role, rules, tone, format	The application
Conversation history	Earlier messages and replies	You and the model
Your new message	The question you just typed	You
Attachments	Files, images, pasted text	You
Retrieved context	Passages the application looked up for this question	The application
Tool definitions	Names and descriptions of tools the model may call	The application
Tool results	Output from tools called earlier in the task	Your systems
Parameters	Model name, length limits and similar settings	The application

Alongside the content, the request carries the usual network details: an API key or session token that identifies the account, your IP address, and headers naming the client software.

Retrieved context: the part you do not see

Many AI tools search your documents before asking the model. This pattern is called retrieval-augmented generation. The application finds passages that look relevant and places them in the request, so that the model can answer from them.

This is useful, and it is also the easiest place for more to leave your device than you expected. You typed one line. The application may have added several pages from your files. A well-designed tool shows you what it attached. The guide on AI answers with sources explains why this pattern is worth the trade.

Agents send more than chats

An AI agent works in a loop. It asks the model what to do next, runs a tool, sends the result back, and repeats. Each tool result becomes part of the next request.

For a coding agent, that means file contents, directory listings, command output, error messages and test logs all go to the provider as the task proceeds. If a command prints an environment variable that holds a password, that password is now in a prompt. If the agent reads a configuration file with credentials in it, the same applies.

This is why the set of tools and files an agent can reach matters so much. The guide on skills, plugins and tool servers covers how those are granted.

What is usually not sent

Files the application never read. A model cannot browse your disk. It sees only what the application places in a request. The risk lies in how much the application is allowed to read, not in the model reaching out.
Your password for the provider. A request carries a token or key, not the password itself.
Other applications' data. Unless a tool or integration has been connected that fetches it.

Treat these as the normal case, not a guarantee. What a particular application reads and uploads in the background, such as indexing, telemetry and crash reports, is a question for that vendor.

What happens at the other end

Once a request arrives, the provider processes it and returns a response. What happens afterwards depends on the provider, the plan and your settings. The points that commonly vary are:

how long prompts and outputs are retained, and in which logs
whether content may be used to train or improve models, and whether that is opt-in or opt-out
whether staff or automated systems may review content, for example for abuse monitoring
where the data is processed geographically
which other companies process it on the provider's behalf

Consumer plans and business or API plans from the same provider often have different terms. Do not rely on a summary written by someone else, including this one. Check the provider's current terms for the exact plan you use.

There may also be an intermediary. If you use an AI feature inside another product, the request may pass through that product's servers before reaching the model provider. That adds a custodian. The guide on data custody in AI explains why each hop matters.

How to keep requests small

Start new conversations for new topics. Old history stops being resent.
Paste the relevant section, not the whole document.
Remove what the model does not need. Names, account numbers and identifiers can often be replaced with placeholders without harming the answer.
Keep secrets out of files and output an agent can read. Use a proper secret store. See where your AI keys and logins should live.
Limit what agents can reach. Give each one the folders and tools the job needs, no more.
Prefer tools that show you the request. If you can see what was attached, you can correct it.

None of this requires avoiding hosted models. It requires knowing that the unit of disclosure is the full request, and shaping that request with care.

This is general information, not legal advice. If you handle personal or regulated data, check your obligations with your own adviser.

Written by Aditya Goyal, AI-assisted. First published at prismlabs.solutions.