A September 14 incident in Headlong’s public engineering account describes an agent creating another identity, starting two web servers and wedging its own wake loop for seven hours. This is the project’s account, not an independently reproduced outage. It explains the pressure behind the next day’s work: keep the agent’s experiments from altering the shared runtime in place.
Headlong is Laude’s open-source experiment in an agent that continues working between human messages. Its launch post describes both agent contributions to the project and accidental self-stops. That makes the boundary unusually consequential. Changing itself is part of the experiment; disabling the machinery that schedules its next thought ends the experiment.
The runtime-isolation commit credits Claude as a co-author. That is public evidence of coding-agent participation in this engineering work, not proof of which lines the agent wrote or of autonomous authorship.
Keep an editable life inside a protected installation
The deployment script renders a systemd service drop-in. It makes the filesystem read-only by default, permits writes to the agent’s home and temporary directories, then places a narrower read-only boundary around the application checkout. The individual identity directory remains writable. That is where the agent keeps its memories, prompts, work and its own repository clone.
These are mount rules for the service’s filesystem view, so they also govern processes the agent starts in the background. They do not depend on every shell command consulting a tool-level permission check. Proposed changes to the shared runtime can still travel through the agent’s own clone and a pull request.
The scope is specific: this is the project’s systemd deployment, not a claim that every Headlong installation has this layout. The setting is on by default in that deployment, can be disabled, and takes effect for a running identity after a restart. The updater installs changed rules without automatically restarting the agent.
The path that looked right and behaved wrong
The team then moved identity data out of the code checkout. Its first implementation left a symbolic link at the old location. The follow-up commit records why that was insufficient: the web discovery code did not walk the linked root, and the intended writable identity path needed special handling in the sandbox. The engineering account says one deployed agent briefly stopped receiving Slack messages through that discovery path.
The replacement uses a bind mount: data lives outside the checkout while existing tools continue to see a directory at the familiar location. The web scanner also learned to traverse a linked root, and the sandbox renderer resolves a symlink if that layout is used. The lesson is in the reversal. Preserving a pathname does not preserve how every consumer discovers or mounts it.
The transferable skill: test the boundary from both sides
We ran the repository’s focused sandbox-rendering and credential-splitting tests: 23 and 19 checks passed. They exercise generated rules, repeated installation, explicit opt-out, moved identity paths, token migration and repeat runs. They do not start a real systemd sandbox. The project separately reports tests inside a service on Ubuntu 24.04; we have not reproduced that deployment.
Builders can borrow a concrete test matrix: prove that an agent can still write its own work, cannot write shared executables, and can be found by the web and messaging services after state moves. Run those checks through the actual consumers, including inside the service’s mount namespace. A configuration string is only one of those receipts.
The credential work exposes another boundary worth testing. The Slack bridge’s bot and app tokens move into an inaccessible file, but the migration initially copies the bot token into HEADLONG_ALERT_TOKEN so alerts keep working. The security notes say the separation is incomplete until that copy is replaced with a dedicated alert-only credential. Renaming a secret does not reduce its authority.
Headlong still permits outbound traffic and leaves substantial agent-owned state writable. This is a boundary around a particular failure mode, not complete containment. Its next convincing receipt would pair the intended read/write behavior in a running deployment with a genuinely separate alert credential. The agent can keep changing its work; the machinery that wakes it should survive the attempt.