Local execution boundary
Run local commands inside policy-governed filesystem, process, resource, and network boundaries without a Docker daemon or cloud VM control plane.
Technical preview
OS-native sandboxing for local AI agent execution, with Windows as the complete first-class backend and experimental macOS/Linux managed-proxy enforcement.
Run local commands inside policy-governed filesystem, process, resource, and network boundaries without a Docker daemon or cloud VM control plane.
Windows is the complete first-class path; macOS and Linux support portable filesystem, network-deny, and experimental network.proxy execution.
Integrate through the CLI, JSON-RPC stdio, service stdio, structured errors, audit events, and black-box conformance tests.
Get started
Download the Windows release archive and keep these executables in the same directory:
runseal.exerunseal-windows-sandbox-setup.exerunseal-command-runner.exe.\runseal.exe setup windows-sandbox --cwd C:\path\to\workspace --elevate
.\runseal.exe capabilities
.\runseal.exe exec --json --policy workspace-write --network disabled --cwd C:\path\to\workspace -- whoami.exe
Windows sandbox support requires Windows 10 1809 / build 17763 or newer. Use --elevate to request UAC when first setup cannot run in the current shell. Sandboxed execution fails closed when setup is missing or stale.
Current behavior
Use sandbox_levels, network_modes, and feature_statuses from getCapabilities for client decisions.
| Capability | Windows | macOS | Linux |
|---|---|---|---|
danger-full-access | supported | supported | supported |
read-only | supported | supported | supported |
workspace-write | supported | supported | supported |
workspace-contained | strict compliance option | supported (experimental backend) | supported (experimental backend) |
network.disabled | supported | supported | supported |
network.proxy | supported | supported (experimental backend) | supported (experimental backend) |
macOS and Linux support read-only, workspace-write, and workspace-contained with network.disabled and experimental network.proxy. macOS allows only the current execution's managed proxy endpoint; Linux uses an isolated network namespace and execution-local relay. Direct external, unrelated loopback, and unapproved host IPC connections remain denied. Portable contained execution exposes only the workspace, private runtime roots, explicit policy roots, and a minimum read-only system baseline. Backend status and low-level feature statuses remain experimental; clients should key decisions off the public sandbox level and network mode statuses.
Windows remains the reference backend. macOS and Linux track extra hardening evidence for the portable capabilities they claim, including deny-by-default host-read containment.
| Area | Windows reference | macOS portable | Linux portable | Evidence tracked |
|---|---|---|---|---|
| Filesystem levels | read-only and workspace-write supported; workspace-contained available for strict compliance | read-only, workspace-write, and workspace-contained supported on the experimental backend | read-only, workspace-write, and workspace-contained supported on the experimental backend | Shared filesystem conformance plus adversarial external read/write, parent traversal, symlink or junction traversal, protected metadata, and runtime-root cases for claimed capabilities. |
| Network modes | network.unmanaged, network.disabled, and network.proxy supported | network.unmanaged, network.disabled, and network.proxy supported on the experimental backend | network.unmanaged, network.disabled, and network.proxy supported on the experimental backend | Direct pass-through behavior for network.unmanaged; direct socket and HTTP egress denial for network.disabled; managed proxy routing and CONNECT tunneling, environment override resistance, direct TCP/UDP, unrelated-loopback, host-IPC, and inherited-socket bypass denial, credential redaction, audit/event coverage, and public-safe fail-closed output for network.proxy. |
| Setup/readiness | Windows setup readiness supported | No platform setup; reports unsupported Windows setup without blocking portable enforcement paths | No platform setup; reports unsupported Windows setup without blocking portable enforcement paths | Platform-specific setup contract, structured getSetupStatus, setup failure audit/events, and fail-closed behavior when setup is unavailable. |
| Runtime roots and synthetic home | Supported | Experimental | Experimental | Runtime root creation, environment redirect, cleanup, marker spoofing, symlink replacement, partial setup failure, and cross-execution contamination conformance. |
| Process cleanup | Supported | Experimental | Experimental | Timeout, cancellation, child process, shell trampoline, nested process tree, and helper reuse conformance without terminating unrelated processes. |
| Audit/events | Supported | Supported for current portable paths | Supported for current portable paths | Matching execution, denial, setup failure, and network decision events with JSONL audit records that do not expose backend-private details. |
| Adversarial conformance | Required for reference readiness | Tracked for supported portable claims | Tracked for supported portable claims | RFC-0016 manifest cases must pass with public-safe results for the claimed capability; unsupported gaps must stay explicit and fail closed. |
Reference
runseal exec --policy workspace-write --network proxy --cwd /workspace -- python skill.py
runseal exec --policy workspace-write --network disabled --cwd /workspace --timeout-ms 30000 -- whoami
runseal explain-policy --policy workspace-write --network proxy
runseal capabilities
runseal setup windows-sandbox --cwd C:\path\to\workspace --elevate
runseal mcp --stdio --policy workspace-write
runseal rpc --stdio
runseal service --stdio
runseal version
exec accepts --json, --events, --policy, --network, --cwd, and --timeout-ms. Flags must appear before --; the command and its arguments follow --.
Protocol
{
"jsonrpc": "2.0",
"id": 1,
"method": "execute",
"params": {
"command": ["python", "skill.py"],
"cwd": "/workspace",
"policy": "workspace-write",
"network": {"mode": "proxy"},
"timeout_ms": 30000
}
}
getVersion
getCapabilities
getServiceStatus
explainPolicy
getSetupStatus
execute
getExecution
listExecutions
cancelExecution
subscribeEvents
getAuditEvents
tailAudit
disposeSession
Supported execute params are command, cwd, policy, network, stdin, timeout_ms, metadata, and env.
Windows backend
Windows sandbox support requires Windows 10 1809 / build 17763 or newer.
Build helper binaries locally when developing the Windows reference backend:
.\scripts\build-windows.ps1
.\scripts\build-windows.ps1 -Release
Check setup readiness without changing state:
.\target\debug\runseal.exe setup windows-sandbox --cwd C:\path\to\workspace --status
The status payload reports broker, elevated, can_repair, can_run_setup_now, requires_setup, and next_action.
Client guidance
getVersion and getCapabilities before sandboxed execution.runseal mcp --stdio --policy <policy> [--network <mode>] when exposing execution directly to an AI agent. The MCP server exposes only exec; model calls must set command and cwd, and may set timeout_ms and string env overrides subject to policy scrub rules, but not policy, network, or stdin.POLICY_TRANSITION_BUSY unless they use isolated sandbox workers, identities, and setup state.runseal service --stdio when one process should own completed execution state.RUNSEAL_BIN=/path/to/runseal for candidate implementations.{
"mcpServers": {
"runseal": {
"command": "runseal",
"args": ["mcp", "--stdio", "--policy", "workspace-write"]
}
}
}
Use the absolute runseal binary path when the MCP host does not inherit your shell PATH. Restart the host after editing its MCP config, then call the discovered exec tool with command, cwd, optional timeout_ms, and optional string env overrides.
Omit --network for unmanaged direct networking; pass --network disabled only when the MCP host should deny network egress. With --network proxy, commands should use injected proxy environment variables such as HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, GIT_HTTP_PROXY, and GIT_HTTPS_PROXY inside the current execution; do not hardcode a proxy host, port, or credential because RunSeal may attach the execution to a shared local managed proxy broker. RUNSEAL_NETWORK_PROXY_AUTHORIZATION is a per-execution credential for tools that require an explicit Proxy-Authorization header.
Verification
cargo fmt --check
cargo clippy --tests -- -D warnings
cargo test
Windows dogfood smoke:
powershell -NoProfile -ExecutionPolicy Bypass -File scripts\windows-smoke.ps1
Run from an elevated shell, or add -AllowElevation to validate the documented interactive UAC bootstrap path.
Linux or macOS portable smoke:
python3 scripts/portable-probe-smoke.py
Windows contained and network adversarial evidence: read the reproducible evidence snapshot.
Distribution
Pushing a v* tag runs .github/workflows/release.yml, builds native release archives, and publishes SHA-256 checksum files, SHA256SUMS, and a CycloneDX SBOM. Dispatch the same workflow with a tag input to rebuild assets for an existing release.
sha256sum -c runseal-vX.Y.Z-linux-x86_64.tar.gz.sha256
gh attestation verify runseal-vX.Y.Z-linux-x86_64.tar.gz --repo runseal-labs/runseal
Source of truth
The public protocol and policy contract lives in the RFC repository.