What would it be like to give a coding agent its own computer and mostly leave it to work?
I started with a few practical questions. Where would its files live? What would happen to its edits when the machine shut down? When would it still need to ask me before doing something?
Where the agent could work
Two obvious places to start are your own machine and a disposable container.
Let it use your machine. The agent reads and writes your real disk. Edits go straight to your project. Without a separate permission boundary, one bad command can delete something you care about.
Give it a container. Now there's a wall between the agent and your machine. If the only copy of the work lives inside the container, it can disappear when that container is removed.
Boat takes another approach. It gives the agent a full Linux VM with its own desktop and a disk it can come back to after the machine stops. That makes sense when the agent needs to return to the same development setup.
For Mortar, I wanted the agent to be able to open and edit the project files before starting a machine at all.
The trick: separate the files from the computer
The agent doesn't need its files to live on the computer that runs its code. So I split them apart, in a small project I called Mortar.
- The files live in a database. Mortar keeps the project in MongoDB, dressed up to look like a normal folder. A simulated shell lets the agent browse paths like
/src/main.py with familiar commands like ls, cat and grep without starting a sandbox. Writes carry a revision number so the filesystem can reject stale edits.
- The computer is borrowed. When the agent actually needs to run code, Mortar starts a Vercel Sandbox, copies the files in, runs the command, then copies the results back. When the sandbox goes away, the project doesn't.
- A rulebook decides what's allowed. One policy file says what the agent can do freely, what needs my approval, and what is off limits, like secret files. The same file is used to tell the agent the rules and to enforce them, so the agent sees the same policy the tools use.
The interesting part is the trip back. Not everything a program creates should become part of the project. Mortar brings back changed source files, leaves out things like node_modules and caches, refuses huge batches, and tells the agent what it skipped. And if a program deletes a file inside the sandbox, the real copy stays put. Mortar reports the deletion and restores the workspace copy on the next sync.
Marcelo Chaman asks a related question about what an agent needs from its coding environment. Mortar’s answer starts with deciding which copy of the files counts and which changes get to come back.
What it doesn't do yet
This is a small project, and I'd rather be clear about its edges:
- It doesn't check whether the agent's code is correct. It gives the agent a separate place to run checks.
- It's built for one agent at a time. Several agents editing at once would need more work.
- Conversation history lives in memory, so restarting the process forgets the chat. The files survive; the conversation doesn't.
Build your own
Use this prompt to build a small version in your own stack.