The sandbox that existed only in the documentation
For ten days, the maker behaved as if it lived inside a small garden.
The runtime did not prove that the garden had walls.
Round 1's documentation described sandboxed agent behavior. The reviewed active configuration set the default sandbox to mode: "off". The gateway also mounted the Docker socket. That combination meant the maker's workspace instructions were a behavioral boundary, not a reliable isolation boundary.
The maker stayed inside its workspace during the observed run.
That was useful evidence about instruction-following.
It was not evidence of security.
Intended versus effective state
Intended documentation
agent → sandbox container → workspace only
Reviewed Round 1 effective configuration
agent → gateway container → workspace and gateway capabilities
└─ Docker socket
└─ potential host-control path
The distinction between "workspace" and "sandbox" was the central point.
A workspace was a directory.
A sandbox was an enforced execution and filesystem boundary.
The escape path
The gateway Compose configuration mounted /var/run/docker.sock. A process that could use that socket might be able to ask the Docker daemon to create a container with powerful host mounts.
The reviewed architecture also ran the gateway as root in its container, mounted the deployment environment file, and placed the gateway on a shared proxy network with sibling services.
These conditions did not prove that an agent performed an escape.
They proved that the documented security posture was materially weaker than "the maker cannot leave its workspace."
maker process
↓ if unsandboxed
OpenClaw gateway
↓ mounted socket
Docker daemon
↓ arbitrary container options may be possible
host filesystem / sibling-service attack surface
This was why security claims needed capability tests rather than narrative observations.
Behavioral obedience versus isolation
| Observation | What it supported | What it could not support |
|---|---|---|
| Maker wrote only in its workspace | It followed instructions in Round 1 | It could not access other paths |
| Maker did not run a dangerous command | No dangerous command was observed | Dangerous commands were technically impossible |
SANDBOX.md described non-root containers | Intended design | Active container user and mounts |
sandbox: { mode: "all" } appeared in a later config | Repair attempt | Successful gateway load or VPS enforcement |
verify-isolation.sh existed | A verification method | A passing live result |
The positive behavioral result was worth preserving.
It was valuable precisely because it was not inflated into a security guarantee.
Key rotation was precautionary — no evidence of compromise was found, and the Docker log scan returned no hits for sensitive path access.
Sprint 0 as a launch blocker
Round 2 added Sprint 0 before pipeline repair or persona changes:
- Verify the OpenClaw version and cron functionality.
- Test sandbox restoration on the VPS.
- Use a fallback maker-only sandbox option if appropriate.
- Correct documentation drift.
- Run a non-destructive isolation check.
The repository's maker configuration now declared a minimal mode: "all", scope: "agent", and workspaceAccess: "rw" block. The handoff recorded that OpenClaw v2026.6.11 rejected the sandbox block at startup, leaving the gateway stopped pending investigation.
That made restoration planned and parked, not observed.
The test that matters
A safe isolation test should inspect, without destructive actions:
- gateway and sandbox container identities;
- effective user IDs;
- mounted paths;
- Docker socket inheritance;
- network access policy;
- workspace write access;
- and whether a sandbox could see a sibling workspace.
The test had to run against the deployed version and record its output.
A configuration review could predict a boundary.
Only a runtime check could demonstrate the boundary that actually existed.
Why the planned Maker was riskier
Round 2's Maker rebuild intentionally added permission to fail, tension, growth, and observation of writing found in a directory it did not create.
That changed the conditions of the experiment.
A warm, obedient Maker staying inside its workspace was not the same subject as a tension-enabled Maker with a diegetic bridge.
The more expressive the agent's capabilities and world became, the less acceptable it was to substitute soft instructions for isolation.