Folder lock
Fence an agent into the job's folders
A coding agent runs as you, so it can open anything you can. The folder lock narrows that to the folders the job is about, and the kernel enforces it.
Updated
The Forkbench folder lock confines a coding agent to the folders a job is about. Every terminal in a locked Thread starts under a kernel sandbox profile that denies reading and writing anywhere else in your own files, and every process the terminal spawns inherits it. It needs no container, it cannot be lifted from inside, and it does not restrict the network.
Why this exists
An agent in your terminal has your permissions. That covers the repository it is working in, and also the other projects next to it, the credentials in ~/.aws and ~/.ssh, your browser profiles and your documents. Most of the time it has no reason to look.
The trouble is rarely malice. It is thoroughness. An agent debugging a build reads outward until it finds a config. A cleanup that is correct inside the repository is a disaster one directory up. A dependency's install script runs with the same reach the agent has. None of that needs a bad actor, only a wide-open filesystem and a tool that is trying hard.
The usual advice is a rule in a file telling the agent where not to go. A rule is text the model weighs. The public issue trackers have plenty of cases where it was not honoured.
How it works
You tell a Thread which folders the job is about. Usually that is one repository, a scratch directory and wherever it builds into.
- Lock the Thread to those folders. From then on, every terminal in it starts under a generated sandbox profile. The lock applies as a shell starts, so Forkbench offers to restart the Thread's terminals for you.
- Everything the terminal starts inherits it. The agent, the scripts it runs, the build, a package's install hook and the agent's own tool calls are all bound by the same profile, whether or not they know Forkbench exists.
- Carry on working. Inside the allowed folders nothing changes. Outside them, a folder cannot be listed and a file cannot be opened or written.
What stays shut, and what still works
The profile closes the places your own content lives: your home directory, external volumes and network shares, apart from the folders you allowed and the handful of configuration files tools need in order to start. So ~/.ssh, ~/.aws, your other repositories and your Documents are out of reach.
It is deliberately narrow about everything else, because a lock that breaks your tools gets switched off. System paths and your package manager stay readable, so builds run. File metadata stays readable everywhere, so paths resolve and shell completion behaves. What is refused is opening a file or listing a folder you did not allow.
Why the kernel and not a rule
A rule depends on the agent agreeing. A sandbox profile is checked by the operating system on every open, so there is nothing to persuade. It also cannot be lifted from inside: a process that asks for a wider profile is refused by the kernel, which is the difference between a boundary and an honour system.
And compared with a container or a virtual machine, it asks nothing of your setup. Those give a stronger wall, and in exchange you maintain your shell, your tools and your credentials twice, and the things you forget to copy in are the things the agent asks for. The folder lock leaves your machine exactly as it is and narrows one thing.
Folders are half of it
Bounding what an agent can open says nothing about the key it is allowed to use. That is why the lock has a partner: Forkbench's Vault gives a credential to the command that needs it and keeps the value out of the agent's hands. Lock the folders, move the keys, and a fast, loose session has very little left to trip over.
For a pane handling something you did not write, there is a second, separate switch. It cuts that one pane off from the Thread's board, notes and Vault, while its shell and files carry on. The two are independent and can both be on.
The folder lock and the alternatives
Each of these draws a boundary around an agent. They differ in how much of your working setup you rebuild to get it.
| What it confines | What it costs you | Network | |
|---|---|---|---|
| Folder lock | Your files, to the folders you chose | Nothing to build or maintain | Not restricted |
| A rule in CLAUDE.md | Nothing, it is a request | Nothing | Not restricted |
| A devcontainer | The agent, to a container | An environment you maintain twice | Configurable |
| A disposable microVM | The agent, to a throwaway machine | The same, plus the VM | Isolated |
Where it stops
- It does not restrict the network. A locked Thread can still reach the internet. Containing what an agent can open is not the same as containing what it can send.
- It is opt-in, and it starts with the shell. Nothing is locked until you lock it, and a shell that is already running cannot be sealed after the fact. That is why locking offers to restart the terminals.
- It is not a container or a virtual machine. It stops an agent wandering, which is the thing that actually happens. For code you do not trust at all, a microVM is the right tool.
- One sandbox per shell. These profiles do not nest. Inside a locked Thread, a tool that tries to start a second sandbox of the same kind is refused by the kernel, so treat the lock as the boundary for that job.
- It relies on the operating system's sandbox. The lock is built on the kernel sandbox the system provides. If that is unavailable, the control disables itself, so a shell is never started believing it is sealed when it is not.
Frequently asked
How do I stop Claude Code reading files outside my project?
Bound it at the filesystem instead of in the prompt. In Forkbench, lock the Thread to the project's folders and every terminal in it starts under a kernel sandbox profile that denies reading and writing anywhere else in your files. Claude Code and everything it runs inherit that, and it cannot be talked out of it. The step by step is here.
Is the folder lock a sandbox?
It is a filesystem sandbox: it confines a job to the folders you allowed, enforced by the operating system's kernel. It is not a container or a virtual machine and it does not restrict the network. For how the options differ, see sandboxes, containers and VMs compared.
Does the folder lock block network access?
No. It is a lock on folders and says nothing about the network, so a locked Thread can still reach the internet. Keeping a credential from being sent somewhere it should not go is the job of the Vault, which binds a key to its destination.
Will my builds and tools still work inside a locked Thread?
Yes. System paths and your package manager stay readable, file metadata stays readable everywhere so paths and shell completion work, and the configuration files tools need to start are allowed. What is refused is opening or listing your own files outside the folders you chose.
Can an agent turn the folder lock off?
No. The profile is applied when the shell starts and is inherited by everything it spawns. A process that asks for a wider profile is refused by the kernel. Only the person can unlock the Thread, and that takes effect on new terminals.
Is a folder lock better than a rule telling the agent not to read a file?
Yes, because a rule is advice and a lock is enforcement. A line in CLAUDE.md competes with everything else the model is weighing, while a sandbox profile is checked by the operating system on every open. Why a rule does not stop an agent reading .env explains the difference.
Keep reading
- Claude Code permissions: limiting what it can actually touch
- Seatbelt, devcontainers, Docker Sandboxes and VMs compared
- The Vault: let an agent use a key it never reads
- What the sandbox does and does not cover
Sources
Let it run, inside the lines you drew
Lock one job to its folders and watch everything else on your machine stay shut.