Docker Sandbox

A generic skill that provides a secure, temporary Docker sandbox for executing generated code (Python, Node.js, bash, etc.). Agents can use this to verify th...

Security Scan

The skill is internally consistent with its stated purpose (providing Docker-based ephemeral sandboxes) and only requires the docker binary; the instructions mostly match the purpose but a few implementation omissions and operational cautions deserve attention.

Purpose & Capability

Name, description, and runtime instructions all center on running code inside Docker containers. The only required binary is `docker`, which is exactly what this skill needs.

Instruction Scope

Instructions demonstrate creating a local `.sandbox` directory and running containers with --rm, resource limits, and --network none in some examples. However: (1) the Bash example omits resource and network flags that the doc claims are default; (2) the doc relies on the agent/operator to avoid mounting sensitive host paths but does not explicitly warn about the danger of mounting the Docker socket (/var/run/docker.sock); (3) it does not show using non-root users, read-only mounts, no-new-privs, capability drops, or other container-hardening features that are commonly recommended. The mount command uses POSIX shell syntax ($(pwd)) but the metadata lists Windows support; Windows-specific path guidance is missing.

Install Mechanism

Instruction-only skill with no install spec and no code files — lowest-risk delivery mechanism. Nothing is written to disk by the skill itself.

Credentials

The skill requests no environment variables or credentials. Requiring only the `docker` binary is proportionate to the claimed capability.

Persistence & Privilege

Skill is user-invocable and not set always:true. It does not request system-wide changes or persistent presence beyond runtime instructions. Autonomous invocation is allowed (platform default) but not elevated by the skill.

Assessment

This skill is coherent for its stated purpose, but running containers via an agent is powerful and you should take operational precautions before enabling or trusting it. Consider: (1) only give agents access to Docker in tightly controlled environments — the Docker daemon is effectively root on the host; (2) ensure the agent never mounts sensitive host paths (including /, /etc, ~/.ssh) and ensure it cannot mount the Docker socket (/var/run/docker.sock) into containers; (3) prefer additional hardening flags (e.g., --user to avoid root inside container, --read-only, --tmpfs for writable dirs, --security-opt=no-new-privileges, --cap-drop ALL, custom seccomp or AppArmor profiles, and explicit resource limits); (4) ensure examples are consistent (add --network none and resource limits to the bash example) and adapt path syntax for Windows; (5) test the workflow in an isolated VM or disposable host first. If you cannot enforce these operational constraints, do not grant an agent unrestricted ability to run docker on important hosts.

Execute and verify code securely inside isolated temporary containers.

Problem

Agents frequently generate code (Python, JS, Shell scripts) that they need to test before presenting a final solution. Running this code directly on the host machine poses significant security and stability risks.

Solution

The docker-sandbox skill establishes a pattern for agents to provision a temporary, isolated container environment using Docker. Code executes inside the container, captures standard output and error, and cleans up immediately after completion.

Features

• ✅ Host Isolation - Runs code securely away from the host system's file tree and environment variables.
• ✅ Ephemeral Execution - Containers are automatically destroyed (--rm) after the process exits.
• ✅ Multi-environment - Supports Python, Node.js, Go, or any Docker-supported runtime.
• ✅ Resource Controls - Hard constraints on memory and CPU avoid runaway processes.

Usage Guide (For Agents)

When evaluating or testing code, use the following execution abstractions via the host terminal. Prepare your code in a local temporary directory (e.g., ./.sandbox/), then mount it in the container.

1. Python Verification

Run a python script securely with constrained memory and CPU.

# Create a test script
mkdir -p .sandbox
echo 'print("Hello from Docker Sandbox!")' > .sandbox/main.py

# Execute in python sandbox
docker run --rm \
    --memory="512m" \
    --cpus="1.0" \
    --network none \
    -v "$(pwd)/.sandbox:/app" \
    -w /app \
    python:3.10-slim python main.py

2. Node.js Verification

Evaluate JavaScript / Node.js safely.

docker run --rm \
    --memory="512m" \
    --cpus="1.0" \
    --network none \
    -v "$(pwd)/.sandbox:/app" \
    -w /app \
    node:18-alpine node main.js

3. Bash/Shell Verification

Test shell scripts in a generic Alpine environment.

docker run --rm -v "$(pwd)/.sandbox:/app" -w /app alpine sh script.sh

Security Guidelines

1. Mount Minimization: Never mount sensitive host directories (e.g., /etc, ~/.ssh, or /) into the sandbox. Mount only the specifically designated .sandbox or task-related directory.
2. Network Isolation: By default, include --network none in the command to prevent the code from exfiltrating data or initiating unwanted network requests, unless network access is functionally necessary for the test.
3. Privileges: Never use --privileged mode or run containers mapped directly to the root user of the host if preventable.