Docker Sandbox
PassAudited by ClawScan on May 1, 2026.
Overview
This is a coherent instruction-only Docker sandbox guide, but it documents powerful Docker operations that should be used deliberately.
This skill appears reasonable if you want Docker sandbox management. Before using it with untrusted code, choose a safe workspace, prefer deny-by-default network rules, avoid detached or saved sandbox states unless needed, and remove sandboxes when finished.
Findings (3)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Commands run in the sandbox can install packages, run agents, and change files available inside the sandbox.
The skill exposes a broad command-execution pattern inside Docker sandboxes. That is expected for this purpose, but users should still review what commands are run.
docker sandbox exec [options] <sandbox> <command> [args...]
Use explicit sandbox names and workspace paths, review commands before running them, and prefer restrictive network policies for untrusted code.
Untrusted code or agents may be able to read or modify the mounted project workspace.
The sandbox is intentionally connected to the chosen host workspace, so unsafe or destructive actions may affect those project files rather than being completely isolated.
The workspace path on the host is mounted into the sandbox via virtiofs.
Use disposable copies or carefully chosen workspace directories when testing untrusted packages or destructive commands.
A detached process or saved sandbox could continue existing beyond the immediate task if not stopped or removed.
The command reference includes background execution, and the skill also documents saving sandbox state as reusable templates. This persistence is disclosed, but users should keep track of it.
-d # Detach (background)
Avoid detached execution unless needed, and clean up sandboxes with stop or rm after testing.