Can a local model be the only model if the agent is limited to files on one computer?

Casey Holt

Casey Holt

October 7, 2026

Can a local model be the only model if the agent is limited to files on one computer?

Yes, if the limit is real. A local model can be the only model when the agent’s tools are list, read, and edit inside one directory on that computer, there is no shell and no network, and you read the diff before you keep it. It should not be the only model if “files on one computer” means the whole home folder, a browser profile, SSH keys, or a script that can reach the network. The slogan is not the boundary. The directory and the tool list are. Inside that box, calling a frontier model is optional. Outside it, a local model as the only brain will invent a way out or edit the wrong file with confidence.

I use this setup for small edits in a repo that contains no secrets. I do not use it for “the computer.”

The directory that stayed boring

The job was a rename of a config key across three files in one service folder. Tools: list, read, edit. The root of the process was that folder, not my home directory. No shell, so it could not curl, git push, or run a test. The model was local. It edited the right key in two files and the comment in the third. I saw the comment in the diff and fixed it myself. Nothing left the machine. No second model was waiting. That is the yes. The miss was an argument, visible in a diff, on files I had allowed. I can live with that as the only model in the loop.

The same model, pointed at my home directory with a shell “just in case,” is a different product. Home contains keys, a downloads folder, and a browser profile. A shell is a network. I am not describing a clever escape. I am saying the limit you claimed is gone the moment those tools exist. Then I want a stronger model or, better, I want the tools gone. Adding a frontier model does not make a home-directory shell safe. Removing the shell is what makes the local model enough.

A file drawer slightly open in a home office

What “limited to files” has to exclude

A shell, even if you plan to use it yourself in the same process. A browser. An HTTP tool. Git push, or git at all if the credentials helper can talk to a remote. Environment files and key directories inside the allowed folder. If the repo has a .env, the agent can read it, and the contents enter the local log. Move secrets out of the tree before you call the folder safe. A local model does not send the prompt to a vendor. It still writes tool results to disk if you log them.

The path jail has to be the runtime’s, not the prompt’s. “Only edit this folder” in the system text loses to a path like ../.ssh if the tool will open it. I set the tool’s root and I reject absolute paths and parent segments. Then I test by asking the model to read a file outside. The tool should fail. If the model apologizes and the file’s contents appear anyway, the jail is prose. I do not run that agent as local-only. I do not run it at all until the test fails closed.

Symlinks count. A folder that links out to the rest of the disk is not a limit. I check before the first run. This is dull and it is the whole feature.

What the local model still does badly, inside the box

It edits the comment instead of the key. It stops after one file when you named three. It invents a tool name when it wants a test run. Those are reasons to read the diff and to reject unknown tools, not reasons to add a second model on every call. A frontier model is better at the long chain. For a short chain I will review, the local model is enough, and the review is the second opinion. If I am not going to read the diff, the local model is not enough, and neither is a frontier model I also will not read. The unread diff is the problem. The model choice does not fix an unread diff. It changes how often the diff is wrong.

I keep tasks inside what one sitting can check. If the rename is fifty files, I do not leave a local model as the only model overnight. I either split the job or I accept a stronger model and I still read the result. “Files only” is not “unattended.” Unattended plus a weak stop condition is how one wrong edit becomes fifty.

A person comparing two printed pages at a kitchen table

When I add a second model anyway

I add one when the edit is hard to see: a permission change, a migration, anything where a plausible diff can be wrong in a way I have missed before. The second model sees the original sentence and the diff, not the whole transcript. If I cannot get that review, I do the edit myself. I do not add a second model because the folder feels important and I left the shell on. The shell has to go first. A second model with a shell is two ways to leave the disk.

I also add nothing when the files are the product and the change is a comment or a string I can spot. Paying a frontier model to watch a local model change a label is a habit, not a safety control. The diff is the control. I open it.

Logs, backups, and the other copy

A local model can still duplicate a file you did not want duplicated. The edit tool writes the new text. Your logger writes the old text and the prompt. A backup job copies the directory, including the log, to a disk that is not the jail. I keep the log inside the same directory or I turn it off. I do not send it to a cloud “so I can see the trace later.” That send is a network tool you added beside the file agent. If I need the trace, it is a file I open on that machine. The trace of a secret that was in the tree is a second copy of the secret. This is why the tree has to be clean before the model is the only model. Local does not mean forgetful. It means the copies are yours, and you have to decide where they sit.

Backups of the whole disk are fine and they are not the agent’s tool. The agent should not be the thing that starts the backup, and it should not be able to read the backup disk if that disk holds other projects. One directory means one directory. A helpful “also save a copy to Documents” is a second root. I reject destination paths outside the root even when the model explains that Documents is still this computer. This computer was never the promise. The folder was.

How I know the setup has not drifted

Once a month, or whenever I change the model file, I run three checks. Ask for a file outside the root. It must fail and the bytes must not appear in the reply. Ask for a shell command. The name must be rejected, and nothing must execute. Ask for the three-file rename on a copy of the fixture. I read the diff. If all three hold, the local model stays the only model for that folder. If any check fails, I do not “temporarily” point a frontier model at the broken jail. I fix the jail. A stronger model in a broken jail is a faster way to edit the wrong place. The checks are short. Skipping them is how a symlink or a new tool appears and the essay I tell myself stays “files only.”

I write the directory path and the tool names on one line in the project notes. When I cannot remember them without opening a config, the setup has already drifted toward “the computer.” I look. The line is either still true or I stop the agent until it is.

A computer is not a directory

People hear “on one computer” and picture offline. Offline is not the limit that makes a local model enough. The computer has a network stack, other users’ files, and your keys. The agent does not get the computer. It gets one directory and three tools. If you cannot say the directory out loud and you cannot name the three tools, you do not have the setup this answer is about. You have a local model with the usual agent, and that one is not ready to be the only model.

Yes: one directory, list read and edit, no shell, no network, you read the diff, the task is short. That local model can be the only model. The moment the tools can leave the disk, stop calling it files-only and stop leaving it alone with the job.

More articles for you