The Boundary Is Not Only Where Writes Land
The usual picture of an agent sandbox is a fence around a folder. The agent may write inside it and nowhere else, and if the fence holds, the rest of the machine is safe.
Skyflo's sandbox is built that way. When a mission delegates work to a specialist, the specialist gets its own copy of the repository and a macOS sandbox that confines its writes to that copy. When it finishes, Skyflo compares the copy with what it started from and applies the difference to your repository, and only for the paths the specialist was given.
Skyflo 1.4.2 is a small release, and every change in it is a fix to that arrangement. None of the three was an agent escaping its folder. Each one was about something the folder is connected to, which is the part of a sandbox that is easy to leave out of the picture. We found all three ourselves, while running Skyflo on engineering tasks written by people outside the company, and the release notes list them.
Files the Agent Never Saw
A specialist's copy is made from what Git knows about: every tracked file, and every untracked file your ignore rules do not exclude. Files that are ignored, such as .env, a dist folder or a local cache, are deliberately not copied. They are yours, they are often secret, and the specialist does not need them.
The comparison did not follow the same rule. Its record of how things stood before the work began was your whole folder, ignored files included. So a file that was never copied looked, after the work, like a file the specialist had deleted. Two things followed. In a repository with build output, the comparison saw a change outside the specialist's area and refused the work. When the specialist had been given a whole folder, the apparent deletion was inside its area, and applying the work removed that file from your copy.
The fix makes the comparison agree with the copy. What a specialist can change is what Git tracks or would track, judged by your repository's own ignore rules. Ignored files are never copied, never compared and never applied, so there is nothing to delete. Build output and caches a specialist creates while it works are recorded with the result and not applied. When a task genuinely needs an ignored file, such as adding a setting to .env, it has to name that file, and then the real file is copied in and the edit lands on its actual contents.
The lesson is about symmetry. Whatever decides what goes into an agent's copy has to be the same thing that decides what comes back out.
Configuration Is Code
Git reads settings from the repository it is working in, and some of those settings name programs. core.fsmonitor names a program Git runs to learn which files changed. Hooks are programs Git runs at particular moments. A linked worktree has a small .git file that tells Git where the repository really is.
A specialist can write anywhere in its copy, and in a Git repository that included those files. On its own that harms nothing, because the specialist's Git runs inside the same sandbox. But Skyflo also runs Git in that copy from outside the sandbox. After every turn it records what changed, which means running git status as you. A setting planted by the agent would have run its program then, with your permissions. The same is true of the Git you run in your own terminal.
Skyflo 1.4.2 closes this at two layers. The sandbox now refuses writes to Git's settings, its hooks and the .git entry itself, in every repository an agent can write. The index, objects and branches stay writable, so an agent can still commit. And Skyflo's own Git checks now run with the program-running features switched off, which covers a repository that was changed before this release.
The lesson is broader than Git. Anything inside an agent's writable area that a more trusted program will later execute or obey is part of the boundary. Settings files, hook folders and editor task files are code in the only sense that matters: someone else runs them.
Too Tight Is Also Broken
The third fix goes the other way. Many developers install Python with pyenv, which puts small launcher scripts first on their PATH. The launcher reads which version to use from pyenv's folder and then starts that interpreter. The sandbox did not allow reading pyenv's folder, so python failed with command not found in every sandbox mode, and a specialist asked to run a project's tests could not.
A sandbox that stops the person's own tools from working is not safer. It pushes people toward turning it off. In 1.4.2 a pyenv folder that is on the PATH becomes readable to sandboxed agents, never writable, and the interpreters it contains are checked the same way as any other Python, so the libraries they depend on are allowed too. We checked it against the exact PATH a shipped Skyflo sees on a Mac that uses pyenv: python now starts in every sandbox mode, and a write into pyenv's folder is still refused.
What Changes for You
Nothing to configure. Skyflo updates itself to 1.4.2, and the next time it starts, it replaces its sandbox helper with one that enforces the new rules. If you use pyenv, your agents can now run the Python you run.
The earlier essays on this blog describe the harness as the boundary around agent work. These three fixes are what that boundary means at the level of files. It has to cover what the agent's copy leaves out, what the agent's writes will cause others to run, and what the person needs in order to work at all.