The road to Seahaven

Skip to main content

The road to Seahaven

or how I run my agent harnesses without permission prompts

15 August 2026

I avidly use LLMs at work and at home.<br>One thing that's been a concern for me is security: I consider my laptop a safe space, and it's where I put my private files--those I don't entrust to cloud storage.<br>I wouldn't want an LLM to read them, whether accidentally or maliciously.

Enter permission prompts.<br>Every time an agent harness wants to invoke some tool (which includes reading and writing files), it stops and prompts you.<br>But prompts slow you down a lot; there's nothing more frustrating than leaving an agent to work, then returning to an aged permission prompt.<br>They are also not very effective at protecting you: they require cognitive load and discipline.<br>Agent harnesses are moving toward LLM-based judgment of permission prompts themselves, which is another hacky layer atop an existing one.

Pi coding agent takes a different and refreshing tack: it has no permission prompts at all.<br>It delegates the solution to outside of itself -- such as to sandboxes, containers, and virtual machines.<br>At this layer, we can control the agent harness' reality. We can be intentional about what files the harness sees. We can make it so that, if the agent sees a file, it's because we allowed it.<br>If you can get here, permission prompts become redundant.

securing Pi: first iteration

bubblewrap is a command-line utility on Linux that wraps another command, and gives it a different reality:<br>you can control what files and capabilities the nested command has.<br>Similar to the host versus guest duality for virtual machines, the wrapped command becomes a guest, seeing only the parts of the host that we allow.

I found this fapproach online. I don't recall where.<br>I basically copy-pasted a core few lines and enhanced them with my own directories and niceties.

For months, I would launch Pi coding agent in some directory using a custom pi-here command (shell script):

#!/usr/bin/env sh

set -euxo pipefail

wrap-here pi $@<br>wrap-here, in turn, is another custom shell script of about 60 lines.<br>It provides a virtual filesystem where the present working directory is mounted to /work, a temporary empty host directory is mounted to /tmp,<br>system directories are mounted as-is, and nothing else in the home directory is visible.<br>Pi runs inside, and these mounts are all Pi could see.

You're not starting a virtual machine; you're not even starting a container. Startup time is imperceptible.<br>Yet it adds a lot of security -- especially if you're not worried about state-level attacks -- with just a small shim.

It works great! It solved my problem of keeping my laptop's private files private from LLMs.<br>I shared it with my friend Andreas, who adopted it. It worked great for coding.<br>But soon I had a new use-case that I was reaching for frequently -- and the shortcomings showed.

pain point: a single directory is too restrictive

When I wanted to code, I'd do:

cd ~/Repos/nixpkgs<br>pi-here

Now Pi sees the Nixpkgs repository at /work, and it has free rein there. Good.

But sometimes, I wanted to edit documents - and ground my edits in the contents of other documents.<br>Imagine revising a resume, grounded in career stories and my notes from a career book.<br>Now, to match the pi-here interface of opening in the present directory, I would create a "workshop" directory whose purpose was to be a temporary base camp for all the files I needed.<br>I'd have a runbook for myself:<br>run these three commands to copy the files I needed into the base camp,<br>then run pi-here,<br>work on the files,<br>then remember to move the updated file(s) back into their respective homes.

This was manual and error-prone: if I forget to move the updated files back, then I lose any updates I made in my last session!<br>That wasn't sustainable, and I knew I could do better; I just needed to see how far I could take it.

ideation

The problem I was facing was not specific to my resume.<br>I wanted a generic ability to pull in files from several sources on my host filesystem, and present them to the LLM.

I started with a config file in a custom format. Each line specified ro or rw followed by the file path that I wanted to pull in.

GLM-5.2 suggested to centralize these files, such as at ~/.config/my-new-tool/resume, and then I could run a command like my-new-tool resume pi to start pi in a resume environment.<br>Intuitively, I knew I didn't want centralized configs - I wanted to use my existing filesystem organization, to minimize cognitive burden.<br>I wanted my resume workshop to be at ~/documents/2026/career, for example.<br>Here, I could keep base files, and have a config file that specifies additional files to pull in.<br>That was the first implementation GLM-5.2 wrote for me.

But we ran into a complication: there was not a good way to pull in both the present working directory and additional files.<br>Due to how bubblewrap works, doing so created zero-byte files in the...