Solutions
Limit which folders a coding agent can touch
Bound the agent at the filesystem rather than in the prompt. On macOS the kernel does this through a Seatbelt profile applied when a shell starts, which denies reads and writes outside the folders you allowed and is inherited by every process that shell spawns, including build scripts, dependency install hooks and the agent's own tool calls. Unlike an instruction in a config file, it cannot be talked out of, and unlike a container it does not ask you to rebuild your development environment somewhere else.
A coding agent runs in your shell as you, so it can read every file you can read. That includes the other projects in your home directory, the credentials in ~/.aws and ~/.ssh, the browser profiles, and the notes you keep nowhere near the repository. Most of the time it has no reason to look, and most of the trouble is not malice: an agent debugging a build reads outward until it finds a config, and a delete that is correct inside the repository is a disaster one directory up.
The reason to prefer the kernel over a rule is that a rule is advice. A CLAUDE.md line saying not to read .env is a request to a system that decides what to do with text, and the public issue trackers have plenty of cases where it was not honoured. A profile is checked by the kernel on every open, so it does not depend on the agent agreeing. The reason to prefer it over a container is cost: a devcontainer or a microVM gives you a stronger boundary and asks you to maintain your shell, your tools and your credentials twice, and the parts you forget are the parts the agent will ask for. A folder lock leaves your machine exactly as it is and narrows one thing. What it does not do is decide anything about the network, and it cannot be applied to a shell that is already running, so it takes effect as terminals start.
How it works
- 1Decide what the job is actually about. Usually that is one repository, plus a scratch directory and whatever it builds into.
- 2Lock the Thread to those folders. Every terminal in it then starts under a generated Seatbelt profile, and Forkbench offers to restart the terminals, because a running shell cannot be sealed after the fact.
- 3Carry on working. File metadata stays readable everywhere, so paths resolve and shell completion behaves, but a folder you did not allow cannot be listed or opened. System paths and Homebrew are untouched, so builds still run.
- 4Move the credentials the job needs into Vault, so bounding the folders is not the only thing standing between an agent and a key.
- 5For a pane handling something you did not write, seal it off from the Thread as well, so its agent has no board, no notebooks and no Vault to reach.
Straight about the guarantee: A folder lock says nothing about the network: a locked Thread can still reach the internet, and containing what an agent can open is not the same as containing what it can send. It also cannot be applied to a shell that is already running. And it is a boundary for the work, not a jail for a hostile program: it stops an agent wandering, which is the thing that actually happens.