OpenClaw's Sandbox Skill-Path Regression Shows Why Agent Isolation Is More Than Docker

Here is a sentence that should concern anyone running OpenClaw in a sandboxed or multi-tenant context: the execution layer is sandboxed, but the model's startup context still pointed at the host filesystem. That sounds like a documentation problem. It is a security problem.

GitHub issue #91761, filed against v2026.6.5 on a WSL Ubuntu npm-global install, describes a bug where recreating a Docker sandbox and starting a fresh thread still advertised host and global npm skill paths — ~/.npm-global/lib/node_modules/openclaw/skills/gog/SKILL.md — instead of the sandbox-readable materialized paths under /workspace/.openclaw/sandbox-skills/skills/.... The agent could see instructions it could not follow. PR #91791, opened June 10, fixes the startup prompt construction so Docker and SSH sandbox sessions use the materialized paths from the runtime environment rather than the host install location.

The Isolation That Wasn't

Docker is not isolation if the instructions handed to the model describe the host machine. This sounds obvious when stated plainly, but it is a surprisingly common class of agent-runtime bug. The execution layer is correctly sandboxed — mounts, syscalls, and process boundaries are handled — while the context layer still reflects the operator's host environment. The agent then tries to follow instructions that are impossible or unsafe in its actual runtime.

Best case: it fails to load a skill and wastes a turn. Worse case: the platform teaches the model that host paths are valid targets, creating confusing permission requests, broken automation, and misleading audit trails. In a system with tool approvals, filesystem scopes, and delegated subagents, the model's understanding of available resources is part of the security boundary. If that boundary says ~/.npm-global, the agent will eventually try to use it.

The fail-closed behavior in the fix is the right architectural call. If sandbox metadata is missing, prompt construction advertises no skill prompt rather than falling back to unreadable host or global npm paths. Agent prompts are capability descriptors. A wrong capability descriptor is not documentation debt — it is a control-plane bug that can cascade into permission escalation, broken automation, and audit logs that describe actions the agent could not actually take.

What the Fix Actually Does

PR #91791 changes sandbox startup so writable Docker and SSH sandbox sessions use materialized paths under /workspace/.openclaw/sandbox-skills/skills/.... The fix carries the materialized skills workspace and SSH remote workdir through sandbox context, so prompt paths resolve from the runtime environment rather than the host installer layout.

The regression tests are worth noting: they assert that the sandbox prompt contains /workspace/.openclaw/sandbox-skills/skills/gog/SKILL.md, does not contain ~/.npm-global, and does not call the host reusable skill snapshot resolver for the sandboxed path. Those three assertions encode the complete security invariant: the model sees only what it can actually reach.

What Builders Should Do Now

If you are running OpenClaw in Docker or SSH sandboxed environments with writable workspace access, start a fresh sandboxed thread after upgrading and inspect the startup context. Specifically, check what skill paths are mentioned in the agent's system prompt or skill-loading output. If prompts mention host package locations, treat that as a sandbox regression — not a cosmetic issue.

If you are building your own agent platform, copy the lesson: materialize tools and skills inside the execution runtime, then generate prompts from the materialized runtime metadata, never from the host installer layout. The model should reason about what exists in its sandbox, not what exists on the machine that launched it.

The broader principle applies beyond OpenClaw. Any agent system that conflates "where the daemon is installed" with "what the agent can see" has a similar gap. Containerized execution with host-shaped prompts is a sandbox that leaks at the context layer.

Sources: GitHub issue #91761, GitHub PR #91791