Give a Local Coding Agent Safe Access to Your Files

A coding agent earns its keep by doing things to your machine: reading files, rewriting them, running commands. That is also exactly what makes it worth thinking about before you let one loose. The same capability that fixes a bug across twelve files can, if the agent misreads your intent, change the wrong twelve files.

The good news is that the guardrails are simple, layered, and mostly free. You do not need to choose between “powerful agent” and “safe agent.” You stack four cheap protections and get both. We will go through them in order, from the one that is built into a good agent to the one you add when you want maximum isolation: per-action approval, a scoped folder, version control as a safety net, and an optional Docker sandbox.

This guide uses OpenCode as the worked example because its permission model is exactly the behavior you want, but the principles carry to any local coding agent.

Before you start

You need a local coding agent installed and pointed at a model. In the studio that is OpenCode, the desktop app, wired to a model running in Ollama, so nothing leaves the machine. You also want Git available, because version control is the single best safety net in this whole guide and it is already on most developer machines.

The Docker step at the end is optional. Reach for it only when you want a hard wall around the agent. The first three guardrails cover the common case.

Guardrail 1: per-action approval

The first and most important protection is that the agent asks before it acts. A well-behaved coding agent does not silently read your disk and rewrite files. It proposes an action, you approve it, then it proceeds.

OpenCode works exactly this way. When it wants to read a file, edit one, or run a command, it surfaces the action and waits for your approval. You see what it is about to touch before it touches it. That single design choice turns “an agent that can do anything” into “an agent that can do anything you watched it ask to do.”

In practice this means you stay in the loop on the operations that matter. Approve a file read without much thought. Slow down and read carefully when the agent wants to run a command or edit something outside what you expected. The approval prompt is not a nuisance to click through; it is the moment you are exercising control. Treat it like one.

The one habit to build: actually read what you are approving, especially for commands. An agent asking to run a command is the highest-stakes approval you will give it. That is the prompt to read in full.

Guardrail 2: scope it to one project folder

The second guardrail is about blast radius. Even an agent that asks permission can only ask about what it can see. So narrow what it can see.

Point the agent at a single project folder and work from there, not from your home directory or, worse, the root of your disk. When the agent is scoped to one project, the entire universe of files it might read or change is that project. A mistake stays contained inside a folder you already think of as one unit.

This is also just good practice for the work itself. An agent given a tight, well-defined folder gives better results than one pointed at a sprawling mess, because the context it reads is relevant rather than noise. Safety and quality point the same direction here.

The rule we follow: one project, one folder, one agent session. Do not invite an agent to roam your whole machine because it is convenient. The convenience is small and the exposure is large.

Guardrail 3: version control as a safety net

The third guardrail is the one that turns a mistake into a non-event. Before you let an agent loose on a project, commit your work.

git add -A
git commit -m "checkpoint before agent run"

Now you have a clean line in the sand. The agent can edit freely, and if it goes somewhere you did not want, you have an exact, unambiguous record of the state before it started. Reviewing what the agent changed becomes a simple diff against that commit. Undoing it becomes one command:

git restore .

This is the protection that lets you relax. Per-action approval keeps you in the loop, scoping limits the blast radius, but version control is the net under the wire. With a clean commit behind you, the worst case for an agent run is that you read the diff, decide you do not like it, and roll back. That is a recoverable mistake instead of a lost afternoon.

Commit before the run, review the diff after, and keep your real work safe regardless of how the agent behaves. If you are not already in the habit of a checkpoint commit before agent work, this is the one habit from this guide worth building first.

Guardrail 4: a Docker sandbox, when you want a hard wall

The first three guardrails cover the everyday case. When you want more, when you are running an agent more autonomously, or working with code or instructions you do not fully trust, you put a wall around the whole thing with Docker.

Docker runs software in an isolated container: the tool and its dependencies live in a unit that does not have free run of your real machine. Used as a sandbox for an agent, it means commands the agent runs and files it touches happen inside the container, against a copy of the project you mount in, rather than directly against your live system. If something goes wrong inside the box, you throw the box away.

This is the model some agents adopt by default. The Atlas notes that OpenHands, a more autonomous agent in the same category, runs inside Docker as a matter of course, precisely for this isolation. You can apply the same idea around your own agent when the situation calls for it.

Two cautions from the Docker note worth carrying with you, because a sandbox you set up carelessly is not really a sandbox:

• Mounting the Docker socket into a container breaks the wall. Giving a container access to docker.sock lets it spawn sibling containers on your host, which is a real security consideration. Only do that for trusted images, and not as part of a sandbox you are using to contain something you do not trust.
• Networking on Mac and Windows differs. Containers cannot reach the host’s localhost directly; they use host.docker.internal instead. This matters when your sandboxed agent needs to reach a local model server. It is a configuration detail, not a blocker, but it is the thing that trips people up first.

Docker is the heaviest of the four guardrails and the one most people will not need day to day. Keep it in your back pocket for the runs where you want a hard boundary rather than a watchful eye.

Prove it works

Test the guardrails on a folder you do not mind the agent touching. First, confirm per-action approval is real: give the agent a prompt that requires reading a file, and watch it ask before it reads. If it acts without asking, stop and check your settings; that prompt is the guardrail.

Then test the net. Make a clean commit, ask the agent to make a change, review the diff, and roll it back with git restore .. Confirm the folder returns exactly to its committed state. Once you have watched a change appear and then cleanly disappear, you know the safety net holds, and you will work with an agent far more comfortably.

Trade-offs and gotchas

• Approval fatigue is real. Click through enough prompts without reading and you have effectively disabled the guardrail. The protection only works if you actually read the higher-stakes approvals, especially commands.
• Scoping can feel restrictive. Sometimes the agent genuinely needs to see a sibling folder. Widen the scope deliberately for that task, then narrow it again, rather than leaving it wide by default.
• A commit is only a net if it is clean. Checkpoint before the run, not after the agent has already made changes you have not reviewed. A commit that includes the agent’s surprise edits does not protect you from them.
• Docker adds real overhead. A container, a mounted copy of your project, and the networking details are more to manage. It is the right tool for low-trust or highly autonomous runs and overkill for a watched session on your own code.
• The model still matters. None of these guardrails make a weak agent into a careful one. They limit what a mistake can cost; they do not prevent the agent from proposing one. You are still the reviewer.

Where to go next

Once these four guardrails are second nature, the natural next step is to let the agent do more ambitious work with less hand-holding, because you have the net in place to make bigger runs safe. A checkpoint commit, a scoped folder, and a habit of reading command approvals are what let you trust an agent with a multi-file refactor instead of babysitting one line at a time. When the stakes climb higher, the Docker sandbox is there for the runs that warrant a hard wall.

You now have a layered way to give a local coding agent real access to your files without handing it the keys to your whole machine. Curious about these things. You should be too.